View XR-T7234_7485669.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

exar corporation, 48720 kato road, fremont, ca 94538 u (510) 668-7000 u (510) 668-7010 xr xr preliminary xrt7234 e3 uni for atm november ?999 rev. p1.0.0 1.0 system description the XR-T7234 e3 uni ic for atm consists of the following functional sections/blocks. ? transmit section ? transmit utopia interface block ? transmit cell processor block ? transmit e3 framer block ? receive section ? receive utopia interface block ? receive cell processor block ? receive e3 framer block ? microprocessor interface section ? performance monitor section ? test and diagnostic section ? line interface drive and scan section each of these functional sections (and the blocks, within these sections) combine to make a single chip device that is capable of transmitting and receiving atm cell data via a e3 transport medium. 1.1 system level interfacing of the XR-T7234 e3 uni 1.2 ? the system designer, when using the XR-T7234 e3 uni ic for atm, must (at a minimum) interface this chip to the following entities. ? the atm switch (or atm layer processor) ? a local (housekeeping) microprocessor ? the e3 line figures 1 and 2 presents two illustrations of the uni being interfaced to these three entities. a brief discussion on how to interface the uni to these entities follows. interfacing to the atm switch (atmlayerprocessor) whenever an atm switch needs to transmit and receive atm cells to and from the uni, it will typically use some sort of ?atm layer? processing entity to accomplish this processing of cell data. this ?atm switch processing? entity will be referred as the ?atm layer processor? throughout this data sheet. the atm layer processor interfaces with the XR-T7234 e3 uni via the ?utopia bus? and will write in atm cell data (in an 8-bit or 16-bit wide parallel format) into the transmit utopia interface block (of the uni). additionally, the atm layer processor will also receive atm cells (in this same 8-bit or 16-bit wide parallel format) from the receive utopia interface block (within the uni ic). interfacing to the local microprocessor in contrast to the atm layer processor, the ?local? microprocessor ( m p ) interfaces with the uni via the micro- processor interface. this local ?housekeeping? micropro- cessor will typically read and write ?configuration information? from or into the on-chip registers within the uni ic. further, the local microprocessor will respond to uni-generated interrupts, read and write pmdl (path maintenance data link) messages and oam cell data into and from the uni ic. finally, the local microprocessor will ?monitor? the performance of the overall system by peri- odically reading the contents of the ?performance monitor? registers. note: the local m should not be confused with the atm layer processor. the terms ?local m p? and ?atm layer processor? will be used throughout this data sheet in order to make the distinction between these two ?enti- ties?. interfacing the uni to the e3 line the uni can be interfaced to a e3 line that is operating over a copper or optical medium. if the user intends to interface the uni to a copper e3 line, (e.g., over coaxial cable), then he/she must connect the dual rail inputs (rxpos and rxneg) and the dual rail outputs (txpos and txneg) to a e3 line interface unit (liu) ic, (which is transformer-coupled to the e3 line) in order to reliably transmit and receive this data over the copper medium. an example of such an liu are the xr-t7295e (e3 line
8 xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 receiver ic) and the xr-t7296 (e3 line transmitter ic). figure 1 presents an illustration of the ?system-level? interfac- ing of the XR-T7234 e3 uni, when the e3 line signal is transmitted over a copper medium. figure 1.system level interfacing of the XR-T7234 e3 uni (e3 data is transmitted over copper medium). ? additionally, the user would connect the single-rail output pin of the uni (txpos) to the ?electrical? input of an ?electrical to optical? converter; and connect the single-rail input pin of the uni (rxpos) to the ?electrical? output of an ?optical to electrical? converter. the ?electrical to optical? and ?optical to electrical? converters are ?entities? that handle the translation between the electronic and photonic modes. figure 2 presents an illustration of the ?sys- tem level? interfacing of the XR-T7234 e3 uni, when the e3 line signal is transmitted over an optical medium. the remainder of this text will frequently refer to each of these ?entities? as: ? the atm layer processor ? the local microprocessor ? the line interface unit (liu) ic 1.2 internal operation of the XR-T7234 e3uni device whenever an atm switch, that has access to an e3 line, needs to transmit atm cell data to a ?far-end? terminal over the e3 line, it will write the atm cell data into the transmit utopia interface block of the XR-T7234 e3 uni device. afterwards, the transmit utopia interface block will ultimately write this cell data to an internal fifo (referred to as tx fifo throughout this document); wher e it can be read and further processed by the transmit cell processor. the transmit utopia interface block will also perform some parity checking on the data that it receives from the atm layer processor. finally, the transmit utopia interface block will provide signaling tosupport data-flow control atm layer processor line interface unit microprocessor interface XR-T7234 txdata [15:0] rxdata [15:0] to/from far end e3 uni txpos txneg rxpos rxneg atm switch local ?housekeeping? processor d[15:0] wrb_r w ale_as rds_d s rdy_dtck txclav rxclav transmit utopia interface block transmit cell processor transmit e3 framer receive cell processor receive utopia interface block receive e3 framer
9 xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 between the atm layer processor and the uni ic. figure 2.system level interfacing of the XR-T7234 e3 uni (e3 data is transmitted over optical fiber). the transmit cell processor block will read in the atm cell from the tx fifo. it will then (optionally) proceed to t ake the first four octets of this cell and compute the hec byte from these bytes. afterwards the transmit cell processor will insert this hec byte into the 5th octet position within the cell. the transmit cell processor will also (optionally) scramble the payload portion of the cell (bytes 6 through 53) in order to prevent the user data from mimicking framing or control bits/bytes. once the cell has gone through this process it will then be transferred to the transmit e3 framer. if the tx fifo (within the transmit utopia interface block) is depleted and has no (user) cells available, then the transmit cell processor will automatically generate idle cells. these idle cells will be processed in the exact same manner as are the user cells, prior to transmission to the transmit e3 framer block. the transmit cell processor gen- erates these idle cells for ?cell-rate? decoupling purposes. the transmit cell processor also has provisions to allow the user to generate an oam cell via software control. note: the oam cells will be subjected to the same processing (e.g., hec byte calculation/insertion and cell payload scrambling) as are user and idle cells. the transmit e3 framer block will take these atm cells (from the transmit cell processor), and insert this data into the payload portions of each outbound e3 frame. the transmit e3 framer will also generate overhead (oh) bytes that support framing, performance monitoring (the em byte), path maintenance data link as well as alarm and status information originating from the ?near-end? receiver section of the uni. the purpose of these alarm and status information bits is to alert the ?far-end? terminal equipment that the ?near-end? uni receiver has detected some problems in receiving data from it. the transmit e3 framer will output this e3 data stream to an off-chip liu (line interface unit) chip via the txpos, txneg, and txlineclk output pins. the liu chip will take on the responsibility of driving the e3 data out on the e3 transport medium to the ?far-end? terminal. likewise, whenever atm cell data arrives to the uni, over the e3 line, the receive e3 framer block will synchronize itself to this incoming e3 data stream (containing atm cells) via the rxpos, rxneg, and rxlineclk input pins, and pro- ceed to ?strip off? and process the oh bytes of the e3 frame. once all of the oh bytes have been removed, the payload portion of the received e3 frame should consist of atm cells. atm layer processor electrical to optical converter microprocessor interface XR-T7234 txdata [15:0] to/from far end e3 uni txpos rxpos atm switch local ?housekeeping? processor d[15:0] wrb_rw ale_as rds_ds rdy_dtck txclav rxclav transmit utopia interface block transmit cell processor transmit e3 framer receive cell processor receive utopia interface block receive e3 framer optical to electrical converter rxda [15:0]
10 xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 the receive cell processor takes this unframed data-stream of atm cells from the receive e3 framer and performs the following operations: ? cell delineation ? hec byte verification the receive cell processor takes the first four octets of the cell (the header) and computes a hec byte. the receive cell processor will then compare this computed hec value with that of the fifth octet, within the cell. if the two hec values are equal, then the cell is then retained for further processing. if the two hec values are not equal, then the cells with single-bit errors are typically corrected. however, the cell is optionally discarded if multiple-bit errors are detected. cell filtering the receive cell processor will optionally detect and remove idle cells. and can be configured to filter user and oam cells based upon their header byte patterns. cell de-scrambling the receive cell processor will de-scramble the payload portion of the cell (the 6th through the 53rd octet), and pack these octets in with the cell header bytes, and the hec byte for transmission to the receive utopia interface block. once the atm cells have gone through the cell delineation, hec byte verification, cell payload de-scrambling, and cell filtering processes, then they will be written into the rx fifo, within the receive utopia interface block. the receive utopia interface block (like its transmit counterpart) provides the industry standard atm/phy interface functions. the receive utopia interface block will inform the atm layer processor when it is holding atm cell data within the rxfifo that needs to be read. the atm layer processor can then read out this cell data , from the receive utopia interface block, and route it to the remainder of the atm switch for further processing. dc electrical characteristics test conditions: ta = 25c, vcc = 5.0v 5% unless otherwise specified symbol parameter min. typ max. units conditions icc power supply current ma ill data bus tri-state bus leakage current ma vil input low voltage v vih input high voltage vcc v
11 xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 vol output low voltage v voh output high voltage vcc v ioc open drain output leakage current ma ac electrical characteristics test conditions: ta = 25c, vcc = 5.0v 5% unless otherwise specified symbol parameter min. typ max. units conditions transmit utopia interface block (see figure 91) t1 txdata[15:0] to rising edge of txclk setup time ns t2 txdata[15:0] hold time from rising edge of txclk ns t3 txutopia write enable setup time to rising edge of txclk ns t4 txutopia write enable hold time from rising edge of txclk ns t5 txprty setup time to rising edge of txclk ns t6 txprty hold time from rising edge of txclk ns t7 txsoc setup time to rising edge of txclk ns t8 txsoc hold time from rising edge of txclk ns t9 txaddr[4:0] setup time to rising edge of txclk ns t10 txaddr[4:0] hold time from rising edge of txclk ns t11 txclav signal valid (not hi-z) from first txclk rising edge of valid and correct txaddr[4:0] ns t12 txclav signal hi-z from first txclk rising edge of different txaddr[4:0] ns transmit cell processor (gfc serial input port) ? see figure 92 t13 clock period of txgfcclk ns fgfcclk frequency of txgfcclk hz t14 delay from rising edge of txgfcclk to rising edge of txgfcmsb pin ns dc electrical characteristics (continued) test conditions: ta = 25c, vcc = 5.0v 5% unless otherwise specified symbol parameter min. typ max. units conditions
12 xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 t15 pulsewidth of txgfcmsb signal ns t16 txgfc data setup time to rising edge of txgfcclk ns t17 txgfc data hold time from rising edge of txgfcclk ns transmit e3 framer (serial input port) ?see figure 93 ftxohclk frequency of txohclk signal hz t24 period of txohclk clock signal ns t25 delay from rising edge of txohframe signal to rising edge of txohclk signal ns t26 txoh data setup time to rising edge of txohclk signal ns t27 txoh data hold time from rising edge of txo- hclk signal ns t28 txohins signal setup time to rising edge of txohclk ns t29 txohins signal hold time from rising edge of txohclk ns transmit e3 framer (liu interface port) ?see figures 94 and 95 t30 delay time of data on txpos or txneg, following the rising edge of the txlineclk ns transmit e3 framer is configured to update txpos and txneg on the rising edge of txlineclk. t31 delay time of data on txpos or txneg following the falling edge of the txlineclk ns transmit e3 framer is con- figured to update txpos and txneg on the falling edge of txlineclk. ftxlineclk clock frequency of txlineclk hz t32 period of txlineclk clock signal ns t33 bit period of data on txpos or txneg pins ns receive e3 framer (serial output port) ?see figure 96 frxohclk frequency of rxohclk signal hz t34 period of rxohclk clock signal ns t35 delay time from rising edge of rxohclk to rxohframe signal ns ac electrical characteristics (continued) test conditions: ta = 25c, vcc = 5.0v 5% unless otherwise specified symbol parameter min. typ max. units conditions
13 xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 t36 delay time from rising edge of rxohclk to valid data at rxoh ns t37 bit period of data at rxoh ns symbol parameter min. typ max. units conditions receive e3 framer (liu interface port) ?see figures 97 and 98 t38 rxpos/rxneg data setup time to rising edge of rxlineclk ns receive e3 framer is con- figured to sample rxpos and rxneg on the rising edge of rxlineclk. t39 rxpos/rxneg data hold time from rising edge of rxlineclk ns receive e3 framer is con- figured to sample rxpos and rxneg on the rising edge of rxlineclk. t40 rxpos/rxneg data setup time to falling edge of rxlineclk ns receive e3 framer is con- figured to sample rxpos and rxneg on the falling edge of rxlineclk. t41 rxpos/rxneg data hold time from falling edge of rxlineclk ns receive e3 framer is con- figured to sample rxpos and rxneg on the falling edge of rxlineclk. frxlineclk clock frequency of rxlineclk hz t42 period of rxlineclk clock signal ns receive cell processor (gfc serial output port) ?see figure 99 t47 clock period of rxgfcclk ns t48 delay from rising edge of rxgfcclk to rising edge of rxgfcmsb pin. ns t49 pulsewidth of rxgfcmsb signal ns t50 delay from rising edge of rxgfcmsb signal to first valid bit at rxgfc. ns t51 delay from rising edge of rxgfcclk to valid bit at rxgfc. ns t52 pulsewidth of bit at rxgfc output. ns receive utopia interface block (see figure 100) t53 delay time from rising edge of rxclk to data valid at rxdata[15:0] ns ac electrical characteristics (continued) test conditions: ta = 25c, vcc = 5.0v 5% unless otherwise specified symbol parameter min. typ max. units conditions
14 xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 t54 rx utopia read enable setup time to rising edge of rxclk ns t55 delay time from rising edge of rxclk to valid rxprty bit ns t56 delay time from rising edge of rxclk to valid rxsoc bit ns t57 delay time from read enable false to data bus being tri-stated ns t58 delay time from read enable false to rxprty bit being tri-stated ns t59 delay time from read enable false to rxsoc bit being tri-stated ns t60 rxaddr[4:0] setup time to rising edge of rxclk ns t61 rxaddr[4:0] hold time from rising edge of rxclk ns t62 rxclav signal valid (not hi-z) from first rxclk rising edge of valid and correct txaddr[4:0] ns t63 rxclav signal hi-z from first rxclk rising edge of different rxaddr[4:0]. ns microprocessor interface?intel (see figure 101) t64 a8 - a0 setup time to ale_as low ns t65 a8 - a0 hold time from ale_as low ns t66 cs* setup time to ale_as low ns t67 cs* hold time from rds_ds*, wrb_rw* high t68 ale_as hold time to rds_ds* low. ns t69 rds_ds*, wrb_rw* pulse width ns t70 data valid from rds_ds* low. ns t71 data bus floating from rds_ds* high ns t72 data setup time to wrb_rw* high ns t73 data hold time from wrb_rw* high ns t74 high time between reads and/or writes ns microprocessor interface?motorola read operations (see figure 102) t75 a8 - a0 setup time to ale_as high ns ac electrical characteristics (continued) test conditions: ta = 25c, vcc = 5.0v 5% unless otherwise specified symbol parameter min. typ max. units conditions
15 xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 t76 a8 - a0 hold time from ale_as low ns t77 cs* setup time to ale_as low ns t78 wrb_rw setup time (for read) to rdb_ds (data strobe) ns t79 ale_as setup time to rdb_ds (data strobe) low ns t80 data valid from rdb_ds low ns t81 dtack low from rdb_ds low ns t82 cs* high pulse width ns t83 data bus floating from cs* high ns t84 data bus floating from rdb_ds high ns t85 dtack high from rdb_ds high ns microprocessor interface - motorola write operations (see figure 103) t86 wrb_rw setup time (for write) to rdb_ds (data strobe) ns t87 data setup time to falling edge of rdb_ds (data strobe) for write ns t88 data hold time from falling edge of rdb_ds (data strobe) for write ns ac electrical characteristics (continued) test conditions: ta = 25c, vcc = 5.0v 5% unless otherwise specified symbol parameter min. typ max. units conditions
16 xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 pin description pin no. 100 pin package pin no. 160 pinpackage symbol type description 3 1 d15 i/o msb of bi-directional data bus (microprocessor interface section): this pin, along with pins d0?d14, function as the microprocessor interface bi-directional data bus, and is intended to be interfaced to the ?local? microprocessor. this pin is inactive if the microprocessor interface block is configured to operate over an 8 bit data bus. 2 taos o ?transmit all ones signal? (taos) command (for the xr-t7296 e3 line transmitter ic). this output pin is intended to be connected to the taos input pin of the xr-t7296 e3 line transmitter ic. the user can control the state of this output pin by writing a ?0? or ?1? to bit 4 (taos) of the line interface drive register (address = 84h). if the user commands this signal to toggle ?high? then itwill force the xr-t7296 e3 line transmitter ic to transmit an ?all ones? pattern onto the line. conversely, if the user commands this output signal to toggle ?low? then the xr-t7296 e3 line transmitter ic will proceed to transmit data based upon the pattern that it receives via the txpos and txneg output pins. writing a ?1? to bit 4 of the line interface drive register (address = 84h) will cause this output pin to toggle ?high?. writing a ?0? to this bit-field will cause this output pin to toggle ?low?. note: if the customer is not using the xr-t7296 e3 line transmitter ic, then he/she can use this output pin for a variety of other purposes. 4 3 d14 i/o bi-directional data bus (microprocessor interface section): this pin is inactive if the microprocessor interface block is configured to operate over an 8 bit data bus. (please see description for d15) 5 4 d13 i/o bi-directional data bus (microprocessor interface section): this pin is inactive if the microprocessor interface block is configured to operate over an 8 bit data bus. (please see description for d15) 6 5 d12 i/o bi-directional data bus (microprocessor interface section): this pin is inactive if the microprocessor interface block is configured to operate over an 8 bit data bus. (please see description for d15) 6 dmo i ?drive monitor output? input (from the xr-t7296 e3 line transmitter ic). this input pin is intended to be tied to the dmo output pin of the xr-t7296 e3 line transmitter ic. the user can determine the state of this input pin by reading bit 2 (dmo) within the line interface scan register (address = 85h). if this input signal is ?high?, then it means that the drive monitor circuitry (within the xr-t7296 e3 line transmitter ic) has not detected any bipolar signals at the mtip and mring inputs within the last 128 32 bit-periods. if this input signal is ?low?, then it means that bipolar signals are being detected at the mtip and mring input pins of the xr-t7296 device. note: if this customer is not using the xr-t7296 e3 line transmitter ic, then he/she can use this input pin for a variety of other purposes.
17 xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 7 7 moto i motorola/intel processor interface select mode: this input pin allows the user to configure the microprocessor interface to interface with either a ?motorola-type? or ?intel-type? microprocessor/microcontroller. tying this input pin to vcc, configures the microprocessor interface to operate in the motorola mode (e.g., the uni device can be readily interfaced to a ?motorola type? local microprocessor). tying this input pin to gnd configures the microprocessor interface to operate in the intel mode (e.g., the uni device can be readily interfaced to a intel type? local microprocessor). 8 rlol i receive loss of lock indicator?from the xr-t7295e e3 line receiver ic . this input pin is intended to be connected to the rlol (receive loss of lock) output pin of the xr-t7295e e3 line receiver ic. the user can monitor the state of this pin by reading the state of bit 1 (rlol) within the line interface scan register (address = 85h). if this input pin is ?low?, then it means that the phase-locked-loop circuitry, within the xr-t7295e device is properly locked onto the incoming e3 data- stream; and is properly recovering clock and data from this e3 data-stream . however, if this input pin is ?high?, then it means that the phase-locked- loop circuitry, within the xr-t7295e device has lost lock with the incoming e3 data-stream, and is not properly recovering clock and data. for more information on the operation of the xr-t7295e e3 line receiver ic, please consult the ?xr-t7295e e3 integrated line receiver? data sheet. note: if the customer is not using the xr-t7295e e3 line receiver, he/she can use this input pin for other purposes. 8 9 d11 i/o bi-directional data bus (microprocessor interface section): this pin is inactive if the microprocessor interface block is configured to operate over an 8 bit data bus. (please see description for d15) 10 txframe o transmit end of e3 frame indicator: this output pin indicates that the last bit of an outbound e3 frame, is being transmitted from the txpos and txneg output pins. this pin marks the end of e3 frame by pulsing ?high? for one bit period at the end of each frame. 9 11 d10 i/o bi-directional data bus (microprocessor interface section): this pin is inactive if the microprocessor interface block is configured to operate over an 8 bit data bus. (please see description for d15) pin description (continued) pin no. 100 pin package pin no. 160 pinpackage symbol type description
18 xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 12 reqb o receive equalization bypass control output pin?(to be connected to the xr-t7295e e3 line receiver ic). this output pin is intended to be connected to the reqb input pin of the xr-t7295e e3 line receiver ic. the user can control the state of this output pin by writing a ?0? or ?1? to bit 5 (reqb) within the line interface driver register (address = 84h). if the user commands this signal to toggle ?high? then it will cause the incoming e3 line signal to ?by-pass? equalization circuitry, within the xr-t7295e device. conversely, if the user commands this output signal to toggle ?low?, then the incoming e3 line signal with be routed through the equalization circuitry. for information on the criteria that should be used when deciding whether to bypass the equalization circuitry or not, please consult the ?xr-t7295e e3 integrated line receiver? data sheet. writing a ?1? to bit 5 of the line interface drive register (address = 84h) will cause this output pin to toggle ?high?. writing a ?0? to this bit-field will cause this output pin to toggle ?low?. note: if the customer is not using the xr-t7295e e3 line receiver ic, then he/she can use this output pin for a variety of other purposes. 10 13 d9 i/o bi-directional data bus (microprocessor interface section): this pin is inactive if the microprocessor interface block is configured to operate over an 8 bit data bus. (please see description for d15) 11 14 d8 i/o bi-directional data bus (microprocessor interface section): this pin is inactive if the microprocessor interface block is configured to operate over an 8 bit data bus. (please see description for d15) 12 15 vdd *** power supply pin 13 16 d7 i/o bi-directional data bus (microprocessor interface section): (please see description for d15) 14 17 d6 i/o bi-directional data bus (microprocessor interface section): (please see description for d15) 15 18 d5 i/o bi-directional data bus (microprocessor interface section): (please see description for d15) 16 19 d4 i/o bi-directional data bus (microprocessor interface section): (please see description for d15) 17 20 width16 i microprocessor interface block data bus width selector: this input pin allows the user configure the microprocessor interface, of the uni, to operate over either an 8 or 16 bit wide data bus. tying this pin to vcc configures the microprocessor interface data bus width to be 16 bits. tying this pin to gnd configures the microprocessor interface data bus width to be 8 bits. 18 21 d3 i/o bi-directional data bus (microprocessor interface section): (please see description for d15) pin description (continued) pin no. 100 pin package pin no. 160 pinpackage symbol type description
19 xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 22 encodis o encoder (hdb3) disable output pin (intended to be connected to the xr-t7296 e3 line transmitter ic). this output pin is intended to be connected to the encodis input pin of the xr-t7296 e3 line transmitter ic. the user can control the state of this output pin by writing a ?0? or ?1? to bit 3 (encodis) within the line inter- face driver register (address = 84h). if the user commands this signal to toggle ?high? then it will disable the hdb3 encoder circuitry within the xr- t7296 ic. conversely, if the user commands this output signal to toggle ?low?, then the hdb3 encoder circuitry, within the xr-t7296 ic will be enabled. writing a ?1? to bit 3 of the line interface driver register (address = 84h) will cause this output pin to toggle ?high?. writing a ?0? to this bit-field will cause this output pin to toggle ?low?. notes: ( 1) the user is advised to disable the hdb3 encoder (within the xr-t7296 ic) if the transmit and receive e3 framers (within the uni) are configured to operate in the hdb3 line code. (2) if the customer is not using the xr-t7296 e3 line transmitter ic, then he/she can use this output pin for a variety of other purposes. 19 23 d2 i/o bi-directional data bus (microprocessor interface section): (please see description for d15) 24 txlev o transmit level select output (to be connected to the xr-t7296 e3 line transmit ic). this output pin is intended to be connected to the txlev input pin of the xr-t7296 e3 line transmitter ic. the user can control the state of this output pin by writing a ?0? or a ?1? to bit 2 (txlev) within the line inter- face driver register (address = 84h). if the user commands this signal to tog- gle ?high? then it will cause the xr-t7296 e3 line transmitter to increase the amplitude of its output signal on the line, in order to drive the signal over cable lengths of greater than 225 ft. therefore, the user is recom- mended to set this output ?high?, if he/she is driving e3 line signals over 225 ft (or more) of cable. conversely, if the user is driving e3 line signals over less t han 225 ft of cable, then he/she is recommended to set this out- put pin ?low?. writing a ?1? to bit 2 of the line interface drive register (address = 84h) will cause this output pin to toggle ?high?. writing a ?0? to this bit-field will cause this output pin to toggle ?low?. note: if the customer is not using the xr-t7296 e3 line transmitter ic, then he/she can use this output pin for a variety of other purposes. 20 25 d1 i/o bi-directional data bus (microprocessor interface section): (please see description for d15) pin description (continued) pin no. 100 pin package pin no. 160 pinpackage symbol type description
20 xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 26 rloop o remote loopback output pin (to the xr-t7296 e3 line transmitter ic). this output pin is intended to be connected to the rloop input pin of the xr-t7296 e3 line transmitter ic. the user can command this signal to toggle ?high? and, in turn, force the xr-t7296 e3 line transmitter into the ?remote loopback? mode. conversely, the user can command this signal to toggle ?low? and allow the xr-t7296 device to operate in the normal mode. (for a detailed description of the xr-t7296 e3 line trans- mitter?s operation during remote loopback, please see the xr-t7296 e3/sts-1, e3 integrated line transmitter?s data sheet). writing a ?1? to bit 1 of the ?line interface drive register (address = 84h) will cause this output pin to toggle ?high?. writing a ?0? to this bit-field will cause the rloop output to toggle ?low?. note: if the customer is not using the xr-t7296 e3 line transmitter ic, then he/she can use this output pin for a variety of other purposes. 21 27 d0 i/o bi-directional data bus (microprocessor interface section): (please see description for d15) 28 lloop o local loopback output pin (to the xr-t7296 e3 line transmitter ic). this output pin is intended to be connected to the lloop input pin of the xr-t7296 liu ic. the user can command this signal to toggle ?high? and, in turn, force the liu into the ?local loopback? mode. (for a detailed description of the xr-t7296 e3 line transmitter?s operation during local loopback, please see the xr-t7296 e3/sts-1, e3 integrated line transmitter?s data sheet). writing a ?1? to bit 1 of the ?line interface drive register (address = 84h) will cause this output pin to toggle ?high?. writing a ?0? to this bit-field will cause the rloop output to toggle ?low?. note: if the user is not using the xr-t7296 e3 line transmitter ic, then he/she can use this output pin for a variety of other purposes. 22 29 intb* o interrupt request output: this open-drain, active-low output signal will be asserted when the uni device is requesting interrupt service from the local microprocessor. this output pin should typically be connected to the ?interrupt request? input of the local microprocessor. 30 rxlcd o loss of cell delineation indicator: this active-high output pin will be asserted whenever the receive cell processor has experienced a ?loss of cell delineation?. this pin will return ?low? once the receive cell processor has regained cell delineation. 23 31 gnd *** ground pin signal pin description (continued) pin no. 100 pin package pin no. 160 pinpackage symbol type description
21 xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 24 32 csb* i chip select input: this active-low input signal selects the microprocessor interface section of the uni device and enables read/write operations between the ?local? microprocessor and the uni on-chip registers and ram locations. 25 33 rdb_ds i read data strobe (intel mode): if the microprocessor interface is oper- ating in the intel mode, then this input will function as the rd* (read strobe) input signal from the local m p . once this active-low signal is asserted, then the uni will place the contents of the addressed registers (within the uni) on the microprocessor data bus (d[15:0]). when this signal is negated, the data bus will be tri-stated. data strobe (motorola mode): if the microprocessor interface is operating in the motorola mode, then this pin will function as the active-low data strobe signal. 34 rxgfc o receive gfc nibble field serial output pin: this pin, along with the rxgfcclk and the rxgfcmsb pins form the ?receive gfc nibble-field? serial output port. this pin will serially output the contents of the gfc nibble field of each valid cell that is processed through the receive cell processor. this data is serially clocked out of this pin on the rising edge of the rxgfcclk signal. the most significant bit (msb) of each gfc value is designated by a pulse at the rxgfcmsb output pin. notes: 1. the gfc nibble field serial output port is only available for the 160 pin packaged device. 2. the ?receive gfc nibble-field? serial output port will only output the gfc nibble-field values of ?valid? cells; not idle cells. 26 35 wrb_rw i write data strobe (intel mode): if the microprocessor interface is operating in the intel mode, then this active-low input pin functions as the wr* (write strobe) input signal from the m p . once this active-low signal is asserted, then the uni will latch the contents of the m p data bus, into the addressed register (or ram location) within the uni ic. r/w input pin (motorola mode): when the microprocessor interface section is operating in the ?motorola mode?, then this pin is functionally equivalent to the ?r/w*? pin. in the motorola mode, a ?read? operation occurs if this pin is at a logic ?1?. similarly, a write operation occurs if this pin is at a logic ?0?. 36 nc **** not bonded out 27 37 a8 i address bus input (microprocessor interface?msb (most significant bit): this input pin, along with inputs a0?a7 are used to select the on-chip uni register and ram space for read/write operations with the ?local? microprocessor. 38 nc **** not bonded out pin description (continued) pin no. 100 pin package pin no. 160 pinpackage symbol type description
22 xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 28 39 a7 i address bus input (microprocessor interface): (please see description for a8) 40 nc **** not bonded out 29 41 a6 i address bus input (microprocessor interface): (please see description for a8) 30 42 a5 i address bus input (microprocessor interface): (please see description for a8) 31 43 a4 i address bus input (microprocessor interface): (please see description for a8) 32 44 a3 i address bus input (microprocessor interface): (please see description for a8) 33 45 a2 i address bus input (microprocessor interface): (please see description for a8) 34 46 a1 i address bus input (microprocessor interface): (please see description for a8) 47 rxgfcmsb o received gfc nibble field?msb indicator: this output pin functions as a part of the ?receive gfc-nibble field? serial output port; which also consists of the rxgfc and rxgfcclk pins. this pin pulses ?high? the instant that the msb (most significant bit) of a gfc nibble is being output on the rxgfc pin. notes: 1. the ?receive gfc nibble field? serial output port is only available for the 160 pin packaged devices. 2. the ?receive gfc nibble-field? serial output port will only output the gfc nibble-field values for valid cells. therefore, this output pin will only pulse ?high? while the receive cell processor is processing a valid cell. 35 48 a0 i address bus input (microprocessor interface)?lsb (least significant bit): (please see description for a8) 49 rxgfclk o received gfc nibble serial output port clock signal: this output pin functions as a part of the ?receive gfc nibble-field? serial output port; also consisting of the rxgfc and rxgfcmsb pins. this pin pro- vides a clock pulse which allows external circuitry to latch in the gfc nib- ble-data via the rxgfc output pin. 36 50 rxclk i receive utopia interface clock input: the byte (or word) data, on the receive utopia data bus is updated on the rising edge of this signal. the receive utopia interface block can be clocked at 25 mhz, 33 mhz, or 50 mhz. 51 rxcellrxed o receive cell processor?cell received indicator: this output pin pulses ?high? each time the receive cell processor receives a new cell from the receive e3 framer. pin description (continued) pin no. 100 pin package pin no. 160 pinpackage symbol type description
23 xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 37 52 gnd *** ground pin signal 53 rxdata15 o receive utopia data bus input (msb): this output pin, along with rxdata14 through rxdata0 functions as the receive utopia data bus. atm cell data that has been received from the ?far-end? uni is output on the receive utopia data bus, where it can be read and processed by the atm layer processor. note: this pin is only available for the 160 pin package version. 38 54 rxdata7 o receive utopia data bus output: this output pin, along with rxdata14 through rxdata0 functions as the receive utopia data bus. atm cell data that has been received from the ?far-end? uni is output on the receive utopia data bus, where it can be read and processed by the atm layer processor. 55 rxdata14 o receive utopia data bus output: this output pin, along with rxdata14 through rxdata0 functions as the receive utopia data bus. atm cell data that has been received from the ?far-end? uni is output on the receive utopia data bus, where it can be read and processed by the atm layer processor. note: this pin is only available for the 160 pin package version. 39 56 rxdata6 o receive utopia data bus output: this output pin, along with rxdata14 through rxdata0 functions as the receive utopia data bus. atm cell data that has been received from the ?far-end? uni is output on the receive utopia data bus, where it can be read and processed by the atm layer processor. 57 rxdata13 o receive utopia data bus output: this output pin, along with rxdata14 through rxdata0 functions as the receive utopia data bus. atm cell data that has been received from the ?far-end? uni is output on the receive utopia data bus, where it can be read and processed by the atm layer processor. note: this pin is only available for the 160 pin package version. 40 58 rxdata5 o receive utopia data bus output: this output pin, along with rxdata14 through rxdata0 functions as the receive utopia data bus. atm cell data that has been received from the ?far-end? uni is output on the receive utopia data bus, where it can be read and processed by the atm layer processor. 59 vdd *** power supply pin 41 60 rxdata4 o receive utopia data bus output: this output pin, along with rxdata14 through rxdata0 functions as the receive utopia data bus. atm cell data that has been received from the ?far-end? uni is output on the receive utopia data bus, where it can be read and processed by the atm layer processor. pin description (continued) pin no. 100 pin package pin no. 160 pinpackage symbol type description
24 xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 61 rxdata12 o receive utopia data bus output: this output pin, along with rxdata14 through rxdata0 functions as the receive utopia data bus. atm cell data that has been received from the ?far-end? uni is output on the receive utopia data bus, where it can be read and processed by the atm layer processor. note: this pin is only available for the 160 pin package version. 42 62 rxdata3 o receive utopia data bus output: this output pin, along with rxdata14 through rxdata0 functions as the receive utopia data bus. atm cell data that has been received from the ?far-end? uni is output on the receive utopia data bus, where it can be read and processed by the atm layer processor. 63 rxdata11 o receive utopia data bus output: this output pin, along with rxdata14 through rxdata0 functions as the receive utopia data bus. atm cell data that has been received from the ?far-end? uni is output on the receive utopia data bus, where it can be read and processed by the atm layer processor. note: this pin is only available for the 160 pin package version. 43 64 rxdata2 o receive utopia data bus output: this output pin, along with rxdata14 through rxdata0 functions as the receive utopia data bus. atm cell data that has been received from the ?far-end? uni is output on the receive utopia data bus, where it can be read and processed by the atm layer processor. 65 rxdata10 o receive utopia data bus output: this output pin, along with rxdata14 through rxdata0 functions as the receive utopia data bus. atm cell data that has been received from the ?far-end? uni is output on the receive utopia data bus, where it can be read and processed by the atm layer processor. note: this pin is only available for the 160 pin package version. 44 66 vdd *** power supply pin 67 rxdata9 o receive utopia data bus output: this output pin, along with rxdata14 through rxdata0 functions as the receive utopia data bus. atm cell data that has been received from the ?far-end? uni is output on the receive utopia data bus, where it can be read and processed by the atm layer processor. note: this pin is only available for the 160 pin package version. 45 68 rxdata1 o receive utopia data bus output: this output pin, along with rxdata14 through rxdata0 functions as the receive utopia data bus. atm cell data that has been received from the ?far-end? uni is output on the receive utopia data bus, where it can be read and processed by the atm layer processor. pin description (continued) pin no. 100 pin package pin no. 160 pinpackage symbol type description
25 xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 69 rxdata8 o receive utopia data bus output: this output pin, along with rxdata14 through rxdata0 functions as the receive utopia data bus. atm cell data that has been received from the ?far-end? uni is output on the receive utopia data bus, where it can be read and processed by the atm layer processor. note: this pin is only available for the 160 pin package version. 46 70 rxdata0 o receive utopia data bus output?lsb: this output pin, along with rxdata14 through rxdata0 functions as the receive utopia data bus. atm cell data that has been received from the ?far-end? uni is output on the receive utopia data bus, where it can be read and processed by the atm layer processor. 71 gnd *** ground signal pin 47 72 rxsoc o receive utopia interface?start of cell indicator: this output pin allows the atm layer processor to determine the boundaries of the atm cells that are output via the receive utopia data bus. the receive utopia interface block will assert this signal when the first byte (or word) of a new cell is present on the receive utopia data bus; rxdata[15:0]. 73 rxaddr4 i receive utopia address bus input (msb): this input pin, along with rxaddr3 through rxaddr0 functions as the receive utopia address bus inputs. these input pins are only active when the uni device is operating in the multi-phy mode. the receive utopia address bus input is sampled on the rising edge of the rxclk signal. the contents of this address bus are compared with the value stored in the ?rx ut address register (address = 7eh). if these two values match, then the uni will inform the atm layer processor on whether or not it has any new atm cells to be read from the rxfifo; by driving the rxclav output to the appropriate level. if these two address values do not match, then the uni will not respond to the atm layer processor; and will keep its rxclav output signal tri-stated. 48 74 rxprty o receive utopia interface?parity output pin: the receive utopia interface block will compute the odd-parity of each byte (or word) that it will place on the receive utopia data bus. this odd-parity value will be output on this pin, while the corresponding byte (or word) is present on the receive utopia data bus. 75 rxaddr3 i receive utopia address bus input: (see description for rxaddr4) pin description (continued) pin no. 100 pin package pin no. 160 pinpackage symbol type description
26 xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 49 76 rxclav o receive utopia?cell available: the receive utopia interface block will assert this output pin in order to indicate that the rx fifo has some atm cell data that needs to be read by the atm layer processor. the exact functionality of this pin depends upon whether the uni is operating in the ?octet level? or ?cell level? handshake mode. octet level handshaking mode: when the receive utopia interface block is operating in the ?octet-level handshaking? mode; this signal is asserted (toggles ?high?) when at least one byte of cell data exists within the rxfifo (within the receive utopia interface block). this output pin will toggle ?low? when the rxfifo is depleted of atm cell data. cell level handshaking mode: when the receive utopia interface block is operating in the ?cell-level handshaking? mode; this signal is asserted if the rxfifo contains at least one full cell of data. this signal toggle ?low? if the rxfifo is depleted of data, or if it contains less than one full cell of data. multi-phy operation: when the uni chip is operating in the multi-phy mode, this signal will be tri-stated until the rxclk cycle following the assertion of a valid address on the receive utopia address bus input pins (e.g., if the contents on the receive utopia address bus pins match that with the receive utopia address register). afterwards, this output pin will behave in accordance with the ?cell-level handshaking? mode. 50 - gnd **** ground signal pin 77 rxaddr2 i receive utopia address bus input: (see description for rxaddr4) 78 vdd **** power supply pin 51 79 rxaddr0 i receive utopia address bus input?lsb: (see description for rxaddr4) 52 80 rxaddr1 i receive utopia address bus input: (see description for rxaddr4) 53 81 rxenb* i receive utopia interface?output enable: this active-low input signal is used to control the drivers of the receive utopia data bus. when this signal is ?high? (negated) then the receive utopia data bus is tri-stated. when this signal is asserted, then the contents of the byte or word that is at the ?front of the rxfifo? will be ?popped? and placed on the receive utopia data bus on the very next rising edge of rxclk. 54 82 gnd **** ground signal pin 55 83 gnd **** ground signal pin 56 84 tdi nc boundary scan pin: not bonded out. 57 85 vdd **** power supply pin pin description (continued) pin no. 100 pin package pin no. 160 pinpackage symbol type description
27 xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 58 86 rlos i receive los (loss of signal) indicator input (from xr-t7295e e3 line receiver). this input pin is intended to be connected to the rlos (receive loss of signal) output pin of the xr-t7295e e3 line receiver ic. the user can monitor the state of this pin by reading the state of bit 0 (rlos) within the line interface scan register (address = 85h). if this input pin is ?low?, then it means that the xr-t7295e device is detecting a sufficient amount of signal energy on the line, due to the incoming e3 data-stream. however, if this input pin is ?high?, then it means that the xr-t7295e device is not detecting a sufficient amount of signal energy on the line, due to the incoming e3 data-stream, and may be experiencing a ?loss of signal? condition. for more information on the operation of the xr-t7295e e3 line receiver ic, please consult the ?xr-t7295e e3 integrated line receiver? data sheet. note: asserting the rlos input pin will cause the XR-T7234 e3 uni device to declare an ?los (loss of signal) condition. therefore, this input pin should not be used as a general purpose input. 59 87 nc **** not bonded out 88 rxlos o receive e3 framer?loss of signal output indicator: this pin is asserted when the receive e3 framer encounters a string of 32 consecutive 0?s via the rxpos and rxneg pins. this pin will be negated once the receive e3 framer has detected a string of 32 consecutive bits, that does not contain a string of 4 consecutive ?0s?. 60 89 rxoh o receive e3 frame overhead bit serial output pin: this output pin, along with rxohclk and rxohframe, combine to form the ?receive e3 framer oh byte? serial output port. the uni receive e3 framer will extract the overhead bytes from the incoming e3 signal, and serially output these bytes on this output pin on the rising edge of the rxohclk output signal. 90 rxoof o receiver e3 framer??out of frame? indicator: the uni receive e3 framer will assert this output signal whenever it has declared an ?out of frame? (oof) condition with the incoming e3 frames. this signal is negated when the framer correctly locates the fa1 and fa2 frame alignment bytes and regains synchronization with the e3 frame. 61 91 gnd *** ground signal pin 92 rxais o receive ?alarm indication signal? output pin: the uni will assert this pin to indicate that the alarm indication signal (ais) has been identi- fied in the receive e3 data stream. the receive e3 framer will declare an ais condition, if it detects two consecutive e3 frames, each contain- ing 7 or less ?0s?. pin description (continued) pin no. 100 pin package pin no. 160 pinpackage symbol type description
28 xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 62 93 rxohclk o receive e3 framer overhead bytes serial output port clock. this pin, along with the rxoh and rxohframe pins function as the ?receive e3 framer overhead byte? serial output port. this pin functions as a clock signal that can be used by external circuitry to latch and process the serial data from the rxoh pin. 94 nc **** not bonded out 63 95 rxohframe o receive e3 framer overhead byte serial output port?frame boundary indicator: this pin, along with the rxoh and rxohclk signals comprise the ?receive e3 framer oh bit? serial output port. this pin pulses high when the first overhead bit of a e3 frame (e.g., the msb-bit in the frame alignment octet: fa1) is output at the rxoh pin. 96 rxframe o receive boundary of e3 frame output indicator: this output pin indicates the boundary of the incoming e3 frame as they appear, at the rxpos and rxneg inputs. this pin marks the end of a e3 frame by pulsing high for one bit period at the end of each frame. 64 97 rxpos i receive positive data input: the exact role of this input pin depends upon whether the uni is operating in the unipolar or bipolar mode. unipolar mode: this input pin functions as the ?single-rail? input for the ?incoming? e3 data stream. the signal at this input pin will be sampled and latched (into the receive e3 framer) on the ?user-selected? edge of the rxlineclk signal. bipolar mode: this input functions as one of the dual rail inputs for the incoming ami/hdb3 encoded e3 data that has been received from an external line interface unit (liu) ic. rxneg functions as the other dual rail input for the uni. when this input pin is asserted, it means that the liu has received a ?positive polarity? pulse from the line. 65 98 rxneg i receive negative data input: the exact role of this input pin depends upon whether the uni is operating in the unipolar or bipolar mode. unipolar mode: this input pin is inactive, and should be pulled (?low? or ?high?) when the uni is operating in the unipolar mode. bipolar mode: this input pin functions as one of the dual rail inputs for the incoming ami/hdb3 encoded e3 data that has been received from an external line interface unit (liu) ic. rxpos functions as the other dual rail input for the uni. when this input pin is asserted, it means that the liu has received a ?negative polarity? pulse from the line. pin description (continued) pin no. 100 pin package pin no. 160 pinpackage symbol type description
29 xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 66 99 rxlineclk i receiver liu (recovered) clock: this input signal serves three purposes: 1. the receive e3 framer uses it to sample and ?latch? the signals at the rxpos and rxneg input pins (into the receive e3 framer circuitry). 2. this input signal functions as the timing reference for the receive framer block. 3. the transmit e3 framer block can be configured to use this input signal as its timing reference. note: this signal is the recovered clock from the external e3 liu (line interface unit) ic, which is derived from the incoming e3 data. 67 100 nc **** not bonded out 68 101 rxred o receiver red alarm indicator?receive e3 framer: the uni asserts this output pin to denote that one of the following events has been detected by the receive e3 framer: ? los?loss of signal condition ? off?out of frame condition ? ais?alarm indication signal detection 102 nc **** not bonded out 69 103 txinclk i transmit e3 framer?clock signal: the transmit e3 framer can be configured to use this input signal as its timing reference. if this input pin is chosen to be the timing reference, then the user must supply a high quality 34.368 mhz signal to this input pin. in this configuration, frame generation, by the transmit e3 framer, will be asynchronous (with any other timing signals within the uni). however, frame timing will be based upon this clock signal. note: this input pin should be tied to ?gnd? if it is not used as the trans- mit e3 framer timing reference. 104 nc **** not bounded out 70 105 gnd *** ground signal pin 106 nc **** not bonded out 71 107 txframeref i transmit e3 framer?frame reference input pin: the transmit e3 framer can be configured to use this input signal as the ?framing? reference for the transmit e3 framer block. if this input pin is chosen to be the framing reference, then any rising edge at this input will cause the transmit e3 framer to begin its creation a new e3 m-frame. consequently, the user must supply a 8khz clock signal to this input pin. note: this input pin should be tied to ?gnd? if it is not used as the transmit e3 framer frame reference signal. 108 nc **** not bonded out pin description (continued) pin no. 100 pin package pin no. 160 pinpackage symbol type description
30 xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 72 109 txpos o transmit positive polarity pulse: the exact role of this output pin depends upon whether the uni is operating in the unipolar or bipolar mode. unipolar mode: this output pin functions as the ?single-rail? output sig- nal for the ?outbound? e3 data stream. the signal, at this output pin, will be updated on the ?user-selected? edge of the txlineclk signal. bipolar mode: this output pin functions as one of the two dual rail output signals that commands the sequence of pulses to be driven on the line. txneg is the other output pin. this input is typically connected to the tpdata input of the external e3 line interface unit ic. when this output is asserted, it will command the liu to generate a positive polarity pulse on the line. 110 nc **** not bonded out 73 111 txneg o transmit negative polarity pulse: the exact role of this output pin depends upon whether the uni is operating in the unipolar or bipolar mode. unipolar mode: this output signal pulses ?high? for one bit period, at the end or each ?outbound? e3 frame. this output signal is at a logic ?low? for all of the remaining bit-periods of the ?outbound? e3 frames bipolar mode: this output pin functions as one of the two dual-rail output signals that commands the sequence of pulses to be driven on the line. txpos is the other output pin. this input is typically connected to the tndata input of the external e3 line interface unit ic. when this output is asserted, it will command the liu to generate a negative polarity pulse on the line. 74 112 txlineclk o transmit line interface clock: this clock signal is output to the line interface unit, along with the txpos and txneg signals. the purpose of this output clock signal is to provide the liu with timing information that it can use to generate the ami pulses and deliver them over the trans- mission medium to the far-end receiver. the user can configure the source of this clock to be either the rxlineclk (from the receiver portion of the uni) or the txinclk input. the nominal frequency of this clock sig- nal is 34.368 mhz. 75 113 vdd *** power supply pin 114 nc **** not bonded out 76 115 txaisen i transmit ais pattern input: when this input pin is set ?high? the transmit e3 framer will insert the ais (e.g., an all ?1s?) pattern into the e3 output data stream. 116 nc **** not bonded out pin description (continued) pin no. 100 pin package pin no. 160 pinpackage symbol type description
31 xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 77 117 txohins i transmit e3 overhead byte serial input port enable: when the user wishes to input his/her value for the overhead bytes into the outbound e3 data stream, he/she should assert this input pin. when this pin is ?high? then the txoh serial input port will become active, and will began sampling the txoh input pin upon the rising edge of txohclk signal. when this pin is ?low?, then the txoh serial input port will be disabled, and the overhead bytes of the outbound e3 data stream will be internally generated. 118 nc **** not bonded out 78 119 txoh i transmit e3 framer overhead bytes serial input port input: this pin, along with the txohins, txohmsb and txohclk pins comprise the ?transmit e3 framer oh bytes? serial input port. this input pin is active when the txohins input pin is ?high?; and is disabled when txohins is ?low?. when this input pin is active, it will sample the input signal on the rising edge of the txohclk signal. the data that is received via this input will be inserted into the overhead bytes of the outbound e3 frame (via the transmit e3 framer block) 120 tcelltxed o transmit cell processor?cell transmitted indicator: this output pin pulses ?high? each time the transmit cell processor transmits a cell to the transmit e3 framer. 79 121 txohclk o transmit e3 framer overhead bit serial input port?clock signal output. this output clock signal, along with the txoh, txohframe, and txo- hins pins, comprise the ?transmit e3 framer oh bytes? serial input port. when this serial port is active, then the data applied to the txoh input pin will be into the serial port on the rising edge of this clock signal. note: the txohclk signal is always active whether the ?txoh serial input? port is active or not. 80 122 txohframe o transmit e3 framer overhead bytes serial input port?framing signal indicator. this output signal, along with the txoh, txohclk and txohins pins comprise the ?transmit e3 framer oh bytes? serial input port. this output pin pulses ?high? when the value for the first ?x? bit (in f-frame #1) is expected at the txoh input pin. note: this output pin is always active whether the ?transmit e3 framer oh byte? serial input port is active or not. pin description (continued) pin no. 100 pin package pin no. 160 pinpackage symbol type description pin description (contd.)
32 xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 81 123 txenb* i transmit utopia interface block?write enable: this active-low signal, from the atm layer processor enables the data on the transmit utopia data bus to be written into the txfifo on the rising edge of txclk. when this signal is asserted, then the contents of the byte or word that is present, on the transmit utopia data bus, will be latched into the transmit utopia interface block, on the rising edge of txclk. when this signal is negated, then the transmit utopia data bus inputs will be tri-stated. 82 124 txsoc i transmitter?start of cell (soc) indicator input: this input pin is driven by the atm layer processor and is used to indicate the start of an atm cell that is being transmitted from the atm layer device. this input pin must be pulsed ?high? when the first byte (or word) of a new cell is present on the transmit utopia data bus. this input pin must remain ?low? at all other times. 83 125 txprty i transmit utopia data bus?parity input: the atm layer processor will apply the parity value of the byte or word which is being applied to the transmit utopia data bus (e.g., txdata[7:0] or txdata[15:0]) inputs of the uni, respectively. note: this parity value should be computed based upon the odd-parity of the data applied at the transmit data bus. the transmit utopia interface block (within the uni) will independently com- pute the odd-parity value of each byte (or word) that it receives from the atm layer processor and will compare it with the logic level of this input pin. 84 126 txclav o transmit utopia interface?cell available output pin: this output pin supports data flow control between the atm layer processor and the transmit utopia interface block. the exact functionality of this pin depend s upon whether the uni is operating in the ?octet level? or ?cell level? handshaking mode. octet level handshaking: when the transmit utopia interface block is operating in the octet-level handshaking mode, this signal is negated (toggles ?low?) when the txfifo is not capable of handling four more write operations; by the atm layer processor to the transmit utopia interface block. this signal will be asserted when the txfifo is capable of receiving four or more write operation of atm cell data. cell level handshaking: when the transmit utopia interface block is operating the cell-level handshaking mode, this signal is asserted (toggles ?high?) when the txfifo is capable of receiving at least one more full cell of data from the atm layer processor. this signal is negated, if the txfifo is not capable of receiving one more full cell of data from the atm layer processor. multi-phy operation: when the uni chip is operating in the multi-phy mode, this signal will be tri-stated until the txclk cycle following the assertion of a valid address on the transmit utopia address bus input pins (e.g., when the contents on the transmit utopia address bus pins match that within the transmit utopia address register). afterwards, this output pin will behave in accordance with the cell-level handshake mode. pin description (continued) pin no. 100 pin package pin no. 160 pinpackage symbol type description
33 xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 85 127 gnd *** ground signal pin. 128 txdata8 i transmit utopia data bus input: please see description for txdata15 note: this input pin is only available in the 160 pin package version. 86 129 txdata0 i transmit utopia data bus input: please see description for txdata15 130 txdata9 i transmit utopia data bus input: please see description for txdata15 note: this input pin is only available in the 160 pin package version. 87 131 txdata1 i transmit utopia data bus input: please see description for txdata15 132 txdata10 i transmit utopia data bus input: please see description for txdata15 note: this input pin is only available in the 160 pin package version. 88 133 txdata2 i transmit utopia data bus input: please see description for txdata15 134 txdata11 i transmit utopia data bus input: please see description for txdata15 note: this input pin is only available in the 160 pin package version. 89 135 txdata3 i transmit utopia data bus input: please see description for txdata15 136 vdd *** power supply pin 90 137 txdata4 i transmit utopia data bus input: please see description for txdata15 138 txdata12 i transmit utopia data bus input: please see description for txdata15 note: this input pin is only available in the 160 pin package version. 91 139 txdata5 i transmit utopia data bus input: please see description for txdata15 140 txdata13 i transmit utopia data bus input: please see description for txdata15 note: this input pin is only available in the 160 pin package version. 92 141 txdata6 i transmit utopia data bus input : please see description for txdata15 142 txdata14 i transmit utopia data bus input: please see description for txdata15 note: this input pin is only available in the 160 pin package version. 93 143 txdata7 i transmit utopia data bus input: please see description for txdata15 144 txdata15 i transmit utopia data bus input?msb: this input pin, along with txdata14 through txdata0 comprise the transmit utopia data bus input pins. when the atm layer processor wishes to transmit atm cell data through the XR-T7234 e3 uni, it must place this data on these pins. the data, on the transmit utopia data bus is latched into the transmit utopia interface block the rising edge of txclk. note: this input pin is only available in the 160 pin package version. 94 145 vdd *** power supply pin pin description (continued) pin no. 100 pin package pin no. 160 pinpackage symbol type description
34 xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 146 txaddr4 i transmit utopia address bus?msb input: this input pin, along with txaddr3 through txaddr0 comprise the transmit utopia address bus input pins. the transmit utopia address bus is only in use when the uni is operating in the m-phy mode. when the atm layer processor wishes to write data to a particular uni device, it will provide the address of the ?intended uni? on the transmit utopia address bus. the contents of the transmit utopia address bus input pins are sampled on the rising edge of txclk. the e3 uni will compare the data on the transmit utopia address bus input pins with the pre-programmed contents of the txut address register (address = 82h). if these two values are identical and if the txenb pin is asserted, then the txclav output pin will be driven to the appropriate state (based upon the txfifo fill level) for the cell level handshake mode of operation. 95 147 txaddr0 i transmit utopia address bus input?lsb: (see description for txaddr4) 148 txaddr3 i transmit utopia address bus input: (see description for txaddr4) 96 149 txaddr1 i transmit utopia address bus input: (see description for txaddr4) 150 txaddr2 i transmit utopia address bus input: (see description for txaddr4) 97 151 txclk i transmit utopia interface clock: the transmit utopia interface clock is used to latch the data on the transmit utopia data bus, into the transmit utopia interface block. this clock signal is also used as the timing source for circuitry used to process the atm cell data into and through the txfifo. during multi-phy operation, the data on the transmit utopia address bus pins is also sampled on the rising edge of txclk. 152 gnd *** ground signal pin 98 153 gnd *** ground signal pin 154 txgfcmsb o transmit gfc nibble-field serial input port?msb indicator: this signal, along with txgfc and txgfcclk combine to function as the ?transmit gfc nibble field? serial input port. this output signal will pulse ?high? when the msb (most significant bit) of the gfc nibble (for a given valid cell) is expected at the txgfc input pin. note: the ?transmit gfc nibble-field? serial input port only inserts the gfc value into valid cells. therefore, this output pin will only pulse ?high? when the transmit cell processor is processing a ?valid? cell. this output pin will not pulse ?high? when the transmit cell processor is processing idle cells. 99 155 resetb i reset input: when this ?active-low? signal is asserted, the uni device will be asynchronously reset. additionally, all outputs will be ?tri-stated?, and all on-chip register will be reset to their default values. pin description (continued) pin no. 100 pin package pin no. 160 pinpackage symbol type description
35 xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 156 txgfcclk o transmit gfc nibble field serial input port clock: this signal, along with txgfc, and txgfcmsb combine to function as the ?transmit gfc nibble-field? serial input port. the ?transmit gfc nibble-field? serial input port uses this output clock signal to sample the values applied to the txgfc pin, on its rising edge. this pin will provide four rising edges for each valid cell being transmitted. 100 157 ale_as i address latch enable/address strobe: this input is used to latch the address (present at the microprocessor interface address bus, a[8:0]) into the uni microprocessor interface circuitry and to indicate the start of a read/write cycle. this input is active-high in the intel mode (moto = ?low?) and active-low in the motorola mode (moto = ?high?). 158 txgfc i transmit gfc nibble-field serial input port: this signal, along with txgfcclk and txgfcmsb combine to function as the ?transmit gfc nibble-field? serial input port. the user will specify the value of the gfc field, within a given valid (user or oam) atm cell, by serial transmitting its four bit value into this input. each of these four bits will clocked into the uni via rising edge of the txgfcclk clock output signal. note: the ?transmit gfc nibble-field? serial input port will only insert the gfc nibble field value into valid cells. therefore, this input pin will only read in the gfc nibble value when a valid cell is being processed. 1 159 gnd *** ground signal pin 2 160 rdy_dtck o ready or dtack: this ?active-low? output pin will function as the ready output, when the microprocessor interface is running in the ?intel? mode; and will function as the dtack output, when the microprocessor interface is running in the ?motorola? mode. ?intel? mode?ready output: when the uni negates this output pin (e.g., toggles it ?low?), it indicates (to the m p ) that the current read or write cycle is to be extended until this signal is asserted (e.g., toggled ?high?). ?motorola? mode?dtack (data transfer acknowledge) output: the uni device will assert this pin in order to inform the local micropro- cessor that the present read or write cycle is nearly complete. if the uni device requires that the current read or write cycle be extended, then the uni will delay its assertion of this signal. the 68000 family of m p s requires this signal from its peripheral devices, in order to quickly and properly complete a read or write cycle. pin description (continued) pin no. 100 pin package pin no. 160 pinpackage symbol type description
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 36 principle of operation 2.0 the user network interface (uni) the term uni refers to an interface between an atm user or end-point (e.g., workstations, bridges, routers, private switches) and an atm network node (typically a switch). the uni could conform to any of a number of physical transmission media standards including the synchronous as well as the pleisochronous digital hierarchies. figure 3 illustrates an example of a possible application of the XR-T7234 uni. figure 3.an example of an application of the XR-T7234 uni. video camera mpeg encoder video monitor mpeg decoder video camera mpeg encoder video monitor mpeg decoder sar sar sar sar user terminals ieee 802.5 token ring network router local area network (10baset) user terminals router atm switch atm switch XR-T7234 e3 uni mpeg data atm cells atm cells XR-T7234 e3 uni tcp/ip data utopia data bus tcp/ip data e3 transport medium utopia data bus user a user b user d user c e3 liu e3 liu hub
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 37 the XR-T7234 uni can functionally be subdivided into 6 different sections, as shown in figure 4. figure 4.functional block diagram of the XR-T7234 e3 uni. these functional blocks are: ? microprocessor interface and programmable registers ? test and diagnostic section ? line interface drive and scan section ? transmit section ? receive section ? performance monitors each of these functional blocks will be discussed in detail below. microprocessor interface (programmable registers and interrupt block) test and loopback line i/f drive and jtag transmitter receiver receive e3 framer performance monitor transmit cell processor tx utopia interface receive cell processor rx utopia interface a[8:0] wrb_rw rdb_ds csb* ale_as reset intb* d[15:0] width16 moto/intel* rdy_dtck txpos txneg txframe txohclk txlineclk txaisen txframeref txinclk txohins txoh txcelltxed txgfcclk txgfcmsb txgfc txclk txdata[15:0] txprty txsoc txenb rxlineclk rxneg rxpos rlos rxais rxohclk rxoh rxlos rxframe rxoof rxcellrxed rxgfcclk rxgfcmsb rxgfc txclav/tfullb rxclk rxenb rxprty rxdata[15:0] rxsoc rxclav/rxempty rxaddr[4:0] txaddr[4:0] transmit e3 framer lapd transceiver
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 38 3.0 microprocessor interface section andon-chip programmable registers the microprocessor interface section supports communication between the ?local? microprocessor ( m p) and the uni device. in particular, the microprocessor interface section supports the following operations between the local microprocessor and the uni. ? the writing of configuration data into the uni on-chip (addressable) registers. ? the writing of ?outbound? oam cell data into the ?transmit oam cell? buffer (within the uni). ? the writing of an ?outbound? pmdl (path maintenance data link) message into the ?transmit lapd message? buffer (within the uni). ? the uni ic?s generation of an interrupt request to the m p. ? the m ?s servicing of the interrupt request from the uni . ? the monitoring of the uni system?s ?health? by periodically reading the on-chip performance monitor registers. ? the reading of an ?inbound? oam cell data from the ?receive oam cell? buffer (within the uni). ? the reading of an ?inbound? pmdl message from the ?receive lapd? buffer (within the uni). each of these operations (between the local microprocessor and the uni) will be discussed in some detail, throughout this data sheet. figure 5 presents a simple block diagram of the microprocessor interface section, within the uni device. figure 5. simple block diagram of microprocessor interface block of uni. 3.1 the microprocessor interface signals t he uni may be configured into a wide variety of different operating modes and have its performance monitored by software through a standard (local ?housekeeping?) microprocessor, using data, address and control signals. note: this local ?housekeeping? microprocessor should not be confused with the atm layer processor that interfaces to the uni via the transmit and receive utopia interface blocks. a[8:0] wrb_rw rdb_ds csb* ale_as reset intb* d[15:0] width16 moto rdy_dtck microprocessor interface and programmable registers
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 39 the local m configures the uni (into a desired operating mode) by writing data into specific addressable on-chip ?read/write? registers; or on-chip ram. the microprocessor interface provides the signals which are required for a general purpose microprocessor to read or write data into these registers. the microprocessor interface also supports ?polled? and interrupt-driven environments. these interface signals are described below in tables 1, 2, and 3. the micro- processor interface can be configured to operate in the ?motorola? mode or in the ?intel? mode. when the microprocessor interface is operating in the ?motorola? mode, then some of the control signals function in a manner as required by the motorola 68000 family of microprocessors. likewise, when the microprocessor interface is operating in the ?intel? mode, then some of these control signals function in a manner as required by the intel 80xx family of microprocessors . tables 1 lists and describes those microprocessor interface signals whose role is constant across the two modes. table 2 describes the role of some of these signals when the microprocessor interface is operating in the ?intel? mode. likewise, table 3 describes the role of these signals when the microprocessor interface is operating in the ?motorola? mode. table 1. description of the microprocessor interface signals that exhibit constant roles in both the ?intel? and ?motorola? mode s. pin name type description moto i selection input for intel/motorola m p interface. setting this pin to a logic ?high? configures the microprocessor interface to operate in the ?motorola? mode. likewise, setting this pin to a logic ?low? configures the microprocessor interface to operate in the ?intel? mode. width16 i select input for the data bus width: setting this pin to a logic ?high? configures the width of the micro- processor interface data bus width to be 16 bits. likewise, setting this pin to a logic ?low? selects a data bus width of 8 bits. d[15:0] i/o bi-directional data bus for register read or write operations. note: if the ?width16? input is ?low?, then only d[7:0] is active. a[8:0] i nine bit address bus input: this nine bit address bus is provided to allow the user to select an on-chip register or on-chip ram location. csb* i chip select input. this ?active-low? signal selects the microprocessor interface of the uni device and enables read/write operations with the on-chip registers/on-chip ram. intb* o interrupt request output: this ?open-drain/active-low? output signal will inform the local m p that the uni has an interrupt condition that needs servicing.
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 40 table 2. pin description of microprocessor interface signals?while the microprocessor interface is operating in the intel mode. pin name equivalent pin in intel environment type description ale_as ale i address-latch enable: this ?active-high? signal is used to latch the contents on the address bus, a[8:0]. the contents of the address bus are latched into the a[8:0] inputs on the falling edge of ale_as. additionally, this signal can be used to indicate the start of a burst cycle. rdb_ds rd* i read signal: this ?active-low? input functions as the read signal from the local m p. when this signal goes ?low?, the uni microprocessor interface will place the con- tents of the addressed register on the data bus pins (d[15:0]). the data bus pins will be ?tri-stated? once this input signal returns ?high?. wrb_rw wr* i write signal: this ?active-low? input functions as the write signal from the local m p. the contents of the data bus (d[15:0]) will be written into the addressed register (via a[8:0]), on the rising edge of this signal. rdy_dtck ready* o ready output: this ?active-low? signal is provided by the uni device, and indicates that the current read or write cycle is to be extended until this signal is asserted. the local m p will typically insert ?wait? states until this signal is asserted. this output will toggle ?low? when the device is ready for the next read or write cycle. table 3. pin description of the microprocessor interface signals while the microprocessor interface is operating in the motorola mode pin name equivalent pin in motorola environment type description ale_as as* i address strobe: this ?active-low? signal is used to latch the contents on the address bus input pins: a[8:0] into the microprocessor interface circuitry. the contents of the address bus are latched into the uni device on the rising edge of the ale_as signal. this signal can also be used to indicate the start of a burst cycle. rdb_ds ds* i data strobe: this signal latches the contents of the bi-directional data bus pins into the addressed register (within the uni) during a write cycle. wrb_rw r/w* i read/write* input: when this pin is ?high?, it indicate a read cycle. when this pin is low, it indicates a write cycle. rdy_dtck dtack* o data transfer acknowledge: the uni device asserts dtack* in order to inform the cpu that the present read or write cycle is nearly complete. the 68000 family of cpus requires this signal from its peripheral devices, in order to quickly and properly complete a read or write cycle.
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 41 3.2 access in the burst mode the uni device provides the user with the ability to quickly access a series of on-chip registers in consecutive, sequential address order. this feature is known as ?burst mode? operation. a burst access is started by the microprocessor asserting the ale_as pin, like any normal access. however, the subsequent register accesses are completed with- out asserting the ale_as pin. the uni device will automatically, internally increment the address that is being accessed, within its address space. the rdy_dtck pin is used to lengthen the individual register accesses if needed. 3.3 on-chip register organization the microprocessor interface section, within the uni device allows the user to do the following. ? configure the uni into a wide variety of operating modes. ? employ various features of the uni device ? perform status monitoring ? enable/disable and service interrupt conditions all of these things are accomplished by reading from or writing to the many on-chip registers, within the uni device. table 4 lists each of these registers and their corresponding address location within the uni address space. 3.3.1 uni register addressing the array of on-chip registers consists of a variety of register types. these registers are denoted in table 4, as follows: ? r/o?read only registers ? r/w?read/write registers ? rur?reset upon read registers ? sem?semaphore bit-field additionally some of these registers consists of both r/o and r/w bit-fields. these registers are denoted in table 4 as ?combination of r/w and r/o?. the bit-format and definitions for each of these registers are presented in section 3.3.2. table 4. register addressing of the uni programmable registers address read mode register write mode register register type 00h uni operating mode register uni operating mode register r/w 01h uni i/o control register uni i/o control register r/w 02h part number register r/o 03h version number register r/o 04h uni interrupt enable register uni interrupt enable register r/w 05h uni interrupt status register r/o 06h test cell control and status register test cell control and status register (r/w portion only) combination of r/o and r/w 07h future use future use 08h test cell header byte 1 test cell header byte 1 r/w
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 42 09h test cell header byte 2 test cell header byte 2 r/w 0ah test cell header byte 3 test cell header byte 3 r/w 0bh test cell header byte 4 test cell header byte 4 r/w 0ch test cell error accumulator?most significant byte r/o 0dh test cell error accumulator?least significant byte r/o 0eh rx e3 framer configuration and status register?1 rx e3 configuration and status register?1 (r/w portion only) combination of r/o and r/w 0fh rx e3 framer configuration and status register ?2 rx e3 framer configuration and status register?2 combination of r/o and r/w 10h rx e3 framer interrupt enable register?1 rx e3 framer interrupt enable register?1 (r/w portion only) combination of r/o and r/w 11h rx e3 framer interrupt enable register ?2 rx e3 framer interrupt enable register?2 (r/w portions only) combination of r/o and r/w 12h rx e3 framer interrupt status register?1 combination of r/o and rur 13h rx e3 framer interrupt status register?2 combination of r/o and rur 14h rx nr register r/o 15h rx gc register r/o 16h rx ttb-0 register r/o 17h rx ttb-1 register r/o 18h rx ttb-2 register r/o 19h rx ttb-3 register r/o 1ah rx ttb-4 register r/o 1bh rx ttb-5 register r/o 1ch rx ttb-6 register r/o 1dh rx ttb-7 register r/o 1eh rx ttb-8 register r/o 1fh rx ttb-9 register r/o 20h rx ttb-10 register r/o table 4. register addressing of the uni programmable registers (continued) address read mode register write mode register register type
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 43 21h rx ttb-11 register r/o 22h rx ttb-12 register r/o 23h rx ttb-13 register r/o 24h rx ttb-14 register r/o 25h rx ttb-15 register r/o 26h rx e3 lapd control register rx e3 lapd control register r/w 27h rx e3 lapd status register r/o 28h tx e3 framer configuration register tx e3 framer configuration register r/w 29h tx gc byte register tx gc byte register r/w 2ah tx ma byte register tx ma byte register r/w 2bh tx nr byte register tx nr byte register r/w 2ch tx ttb-0 register tx ttb-0 register r/w 2dh tx ttb-1 register tx ttb-1 register r/w 2eh tx ttb-2 register tx ttb-2 register r/w 2fh tx ttb-3 register tx ttb-3 register r/w 30h tx ttb-4 register tx ttb-4 register r/w 31h tx ttb-5 register tx ttb-5 register r/w 32h tx ttb-6 register tx ttb-6 register r/w 33h tx ttb-7 register tx ttb-7 register r/w 34h tx ttb-8 register tx ttb-8 register r/w 35h tx ttb-9 register tx ttb-9 register r/w 36h tx ttb-10 register tx ttb-10 register r/w 37h tx ttb-11 register tx ttb-11 register r/w 38h tx ttb-12 register tx ttb-12 register r/w 39h tx ttb-13 register tx ttb-13 register r/w 3ah tx ttb-14 register tx ttb-14 register r/w 3bh tx ttb-15 register tx ttb-15 register r/w 3ch txfa1 error mask register txfa1 error mask register r/w 3dh txfa2 error mask register txfa2 error mask register r/w table 4. register addressing of the uni programmable registers (continued) address read mode register write mode register register type
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 44 3eh txbip-8 error mask register txbip-8 error mask register r/w 3fh tx e3 lapd status/interrupt register tx e3 lapd status/interrupt register (r/w portions thereof) combination of r/w, r/o, and rur 40h pmon lcv event count register? msb rur 41h pmon lcv event count register? lsb rur 42h pmon framing error event count?msb rur 43h pmon framing error event count?lsb rur 44h pmon received febe event count?msb rur 45h pmon receive febe event count?lsb rur 46h pmon framer parity error event count?msb rur 47h pmon framer parity error event count?lsb rur 48h pmon received single-bit hec error count?msb rur 49h pmon received single-bit hec error count?lsb rur 4ah pmon received multiple-bit hec error count?msb rur 4bh pmon received multiple-bit hec error count?lsb rur 4ch pmon received idle cell count?most significant byte rur 4dh pmon received idle cell count?least significant byte rur 4eh pmon received valid cell count?most significant byte rur 4fh pmon received valid cell count?least significant byte rur 50h pmon discarded cell count? most significant byte rur table 4. register addressing of the uni programmable registers (continued) address read mode register write mode register register type
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 45 51h pmon discarded cell count? least significant byte rur 52h pmon transmitted idle cell count?most significant byte rur 53h pmon transmitted idle cell count?least significant byte rur 54h pmon transmitted valid cell count?most significant byte rur 55h pmon transmitted valid cell count?least significant byte rur 56h pmon holding register r/o 57h one second error status register r/o 58h lcv?one second accumulator register?most significant byte r/o 59h lcv - one second accumulator register - least significant byte r/o 5ah bip8?one second accumulation register?msb r/o 5bh bip8?one second accumulation register?lsb r/o 5ch hec errors?one second accu- mulator register?most significant byte r/o 5dh hec errors?one second accumulator register?least significant byte r/o 5eh rx cp configuration register rx cp configuration register r/w 5fh rx cp additional configuration register rx cp additional configuration register r/w 60h rx cp interrupt enable register rx cp interrupt enable register r/w 61h rx cp interrupt status register rx cp interrupt status register rur 62h rx cp idle cell pattern header byte-1 register rx cp idle cell pattern header byte-1 register r/w 63h rx cp idle cell pattern header byte-2 register rx cp idle cell pattern header byte2 register r/w 64h rx cp idle cell pattern header byte-3 register rx cp idle cell pattern header byte-3 register r/w 65h rx cp idle cell pattern header byte-4 register rx cp idle cell pattern header byte-4 register r/w 66h rx cp idle cell mask byte-1 register rx cp idle cell mask byte-1 register r/w table 4. register addressing of the uni programmable registers (continued) address read mode register write mode register register type
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 46 67h rx cp idle cell mask byte-2 register rx cp idle cell mask byte-2 register r/w 68h rx cp idle cell mask byte-3 register rx cp idle cell mask byte-3 register r/w 69h rx cp idle cell mask byte-4 register rx cp idle cell mask byte-4 register r/w 6ah rx cp user programmable cell filter pattern header byte 1 register rx cp user programmable cell filter pattern header byte 1 register r/w 6bh rx cp user programmable cell filter pattern header byte 2 register rx cp user programmable cell filter pattern header byte 2 register r/w 6ch rx cp user programmable cell filter pattern header byte 3 register rx cp user programmable cell filter pattern header byte 3 register r/w 6dh rx cp user programmable cell filter pattern header byte 4 register rx cp user programmable cell filter pattern header byte 4 register r/w 6eh rx cp user programmable cell filter mask byte 1 register rx cp user programmable cell filter mask byte 1 register r/w 6fh rx cp user programmable cell filter mask byte 2 register rx cp user programmable cell filter mask byte 2 register r/w 70h rx cp user programmable cell filter mask byte 3 register rx cp user programmable cell filter mask byte 3 register r/w 71h rx cp user programmable cell filter mask byte 4 register rx cp user programmable cell filter mask byte 4 register r/w 72h tx cp control/interrupt register tx cp control/interrupt register r/w 73h tx cp oam register sem 74h tx cp hec error mask register tx cp hec error mask register r/w 75h future use future use **** 76h tx cp idle cell pattern header byte-1 register tx cp idle cell pattern header byte - 1 register r/w 77h tx cp idle cell pattern header byte-2 register tx cp idle cell pattern header byte - 2 register r/w 78h tx cp idle cell pattern header byte-3 register tx cp idle cell pattern header byte - 3 register r/w 79h tx cp idle cell pattern header byte-4 register tx cp idle cell pattern header byte - 4 register r/w 7ah tx cp idle cell pattern header byte - 5 register tx cp idle cell pattern header byte - 5 register r/w 7bh tx cp idle cell payload register tx cp idle cell payload register r/w 7ch utopia configuration register utopia configuration register r/w 7dh rx ut interrupt enable/status register rx ut interrupt enable/status register combination of r/w and rur 7eh rx utopia address register rx utopia address register r/w table 4. register addressing of the uni programmable registers (continued) address read mode register write mode register register type
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 47 3.3.2 uni register description this section provides a functional description of each bit-field within each of the on-chip uni registers. note: for all on-chip registers, a table containing the bit-format of the register is presented. additionally, these tables also contain the default values for each of these register bits. finally, the functional description, associated with each register bit-field is presented, along with a reference to a section number, within this data sheet, that provides a more in-depth discussion of the functions associated with this register bit-field. 3.3.2.1 uni operating mode register 7fh future use future use **** 80h tx ut interrupt/status register tx ut interrupt/status register combination of r/w and rur 81h future use future use **** 82h tx utopia address register tx utopia address register r/w 83h tx fifo status register r/o 84h line interface drive register line interface drive register r/w 85h line interface scan register r/o 86h-ddh transmit lapd message buffer transmit lapd message buffer r/w deh-135h receive lapd message buffer receive lapd message buffer r/o 136h-16bh transmit oam cell buffer transmit oam cell buffer r/w 16ch-1a1 receive oam cell buffer receive oam cell buffer r/o address = 00h, uni operating mode register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused disable loc int los enable reset by reg cell loop back line loop back timref sel(1) timref table 4. register addressing of the uni programmable registers (continued) address read mode register write mode register register type
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 48 bit 6?disable loc this ?read/write? bit-field allows the user to enable or disable the ?loss of clock signal? circuit. writing a ?1? to this bit-field disables the ?loss of clock? circuit. writing a ?0? to this bit-field enables the ?loss of clock? circuit. bit 5?int los enable this ?read/write? bit-field allows the user to define the ?loss of signal? (los) declaration criteria that the receive e3 framer will use. at most, the receive e3 framer can declare an los condition if one of the follow- ing two conditions are met. 1. the rxpos and rxneg input pins are ?stuck? at ?0? for 32 or more consecutive bit-periods. 2. the xr-t7295 e3 line receive ic asserts the rlos input pin of the uni (please see section 5.0). writing a ?0? to this bit-field configures the receive e3 framer to declare an los condition only if the rlos input pin is asserted. in this configuration, the receive e3 framer will not declare an los condition if it detects a string of 32 (or more) consecutive ?0s?, in the incoming e3 data stream via the rxpos and rxneg pins. writing a ?1? to this bit-field configures to the receive e3 framer to declare an los condition if either one of the following two conditions occur: ? the rxpos and rxneg input pins are stuck at ?0? for 32 or more consecutive bit-periods. ? if the rlos input pin is asserted. bit 4 reset by reg (reset by register setting) this ?read/write? bit-field allows the local m p / m c to command a reset of the entire uni ic. when the uni is reset, both the txfifo and the rxfifo are flushed, all on-chip registers are reset to their default values, and all configurations are automatically set to their default conditions. writing a ?1? to this bit-field will reset the uni ic. writing a ?0? to this bit-field imposes no change in the uni ic. bit 3??cell loopback? mode this ?read/write? bit-field allows the user to configure the uni to operate in the ?cell loopback? mode. this is a operating mode that is available via the uni test and diagnostic section. when the uni is operating in this mode, then the atm cells that are delineated and pass through the receive cell processor will be routed directly (internally) to the tx fifo (within the transmit utopia interface block). writing a ?1? to this bit-field enables the ?cell loopback? mode. writing a ?0? to this bit-field disables the cell loopback mode. for more information on the cell loopback mode of operation, please see section 4.1.3. bit 2??line loopback? mode this ?read/write? bit-field allows the user to configure the uni to operate in the ?line loopback? mode. this is a operating mode that is available via the uni test and diagnostic section. when the uni is operating in this mode, then the data stream from the txpos and txneg pins of the transmit e3 framer, are (internally) looped back into the receive rxpos and rxneg input pins of the receive e3 framer. writing a ?1? to this bit-field enables the ?line loopback? mode. writing a ?0? to this bit-field disables the ?line loopback? mode. for more information on the line loopback mode of operation, please see section 4.1.1. sel(0) r/o r/w r/w r/w r/w r/w r/w r/w 0 1 1 0 0 0 0 0 address = 00h, uni operating mode register
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 49 bits 1, 0?timrefsel[1, 0] (timing /framing reference select bits?transmit e3 framer) these two ?read/write? bit-fields allows the user to select the timing reference signal for the transmit e3 framer block. the relationship between these two bit-fields and these three parameters are tabulated below. 3.3.2.2 uni i/o control register timrefsel[1, 0] transmit e3 framer timing/framing reference 00 txinclk ? framing is asynchronous from power on. ? framer timing is derived from the 34.386 mhz clock signal, which is applied at thetxinclk pin. (for more information please see section 6.3.3.6.2) 01 txframeref ? framing is derived from the txframeref input (e.g., a new e3 frame is started, upon the rising edge of the txframeref input signal). ? framer timing is derived from the 34.386 mhz clock signal at the txinclk pin. (for more information please see section 6.3.3.6.3) 10 rxlineclk ? framing is derived from the receive e3 framer ? framer timing is derived from the rxline clk input signal. ? (for more information, please see section 6.3.3.6.1) 11 txinclk ? framing is asynchronous from power on. ? framer timing is derived from the 34.368 mhz clock signal, which is applied at the txinclk pin. (for more information please see section 6.3.3.6.2) address = 01h, uni i/o control register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 loc rx loc tx interrupt enable reset ami/hdb3* unipolar/ bipolar* txline clk inv rxline clk inv reframe ro ro r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 50 bit 7?loc rx this ?read-only? bit-field indicates whether or not the uni is currently experiencing a ?loss of rxlineclk signal? event. this uni will set this bit-field to ?1? if it is currently experiencing a ?loss of rxlineclk signal? event. conversely, the uni will clear this bit-field (to ?0?) ifitdetects the presence of the rxlineclk signal. bit 6?loc tx this ?read-only? bit-field indicates whether or not the uni is currently experiencing a ?loss of txinclk signal? event. this uni will set this bit-field to ?1? if it is currently experiencing a ?loss of txinclk signal? event. conversely, the uni will clear this bit-field (to ?0?) if it detects the presence of the txinclk signal. bit 5?int en reset (automatic reset of interrupt enable bits) select this ?read/write? bit-field allows the user to configure the uni to automatically clear the ?interrupt enable? bit of an ?activated? interrupt, during the interrupt service routine. if the user selects this option, then an interrupt will be automatically disabled following its activation. the user must go back and write to the appropriate register(s) in order to enable the interrupt once again. this option is useful in preventing a recursively occurring interrupt from ?tying up the system? and loading down the local m c/ m p . writing a ?1? to this bit-field configures the uni to automatically disable interrupts, following their activation. writing a ?0? to this bit-field configures the uni to leave the interrupt enable bits enabled, following interrupt activation. bit 4?ami/hdb3* (line code) this ?read/write? bit-field allows the user to specify whether the e3 line code should be in the ami (alternate mark inversion) or hdb3 (bipolar, with 4 zero substitution) format. writing a ?1? to this bit-field configures the line code (of the transmit and receive e3 framers) to be ami. writing a ?0? to this bit-field, configures the line code (of the transmit and receive e3 framers) to be hdb3. for more information i nto the ami and hdb3 format, please see sections 6.3.3.7.1.2.1 and 6.3.3.7.1.2.2. note: this bit-field is ignored if bit 3 is ?1?. bit 3?unipolar/bipolar* (line code) this ?read/write? bit-field allows the user to configure the transmit and receive e3 framers to transmit/receive data in a unipolar (single-rail) or in a bipolar (dual-rail) format. if the user selects the ?bipolar? format, then he/she can manipulate bit 4 (of this register) in order to select either the ami or hdb3 line code. writing a ?0? to this bit-field configures the transmit e3 framer to transmit data in a bipolar (dual-rail) format; and the receive e3 framer to receive data from the ?line? in a bipolar (dual-rail) format. writing a ?1? to this bit-field configure s the transmit e3 framer to transmit data to the line, in a unipolar (single-rail) format, and the receive e3 framer to receive data from the ?line? in a unipolar format. for more information on unipolar and bipolar formats, please see sections 6.3.3.7.1.1 and 6.3.3.7.1.2. bit 2?txlineclk inv this ?read/write? bit-field allows the user to configure the transmit e3 framer to update the outbound e3 data on the txpos and txneg output pins, on either the rising or the falling edge of txlineclk. writing a ?0? to this bit-field configures the transmit e3 framer to update txpos and txneg on the rising edge of txlineclk. writing a ?1? to this bit-field configures the transmit e3 framer to update txpos and txneg on the falling edge of txlineclk. for more information on this feature, please see section 6.3.3.7.2.
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 51 bit 1?rxlineclk inv this ?read/write? bit-field allows the user to configure the receive e3 framer to ?sample? the incoming e3 data at the rxpos and rxneg input pins, on either the rising or falling edge of rxlineclk. writing a ?0? configures the receive e3 framer to sample the rxpos and rxneg input pins on the rising edge of the rxlineclk. writing a ?1? configures the receive e3 framer to sample the rxpos and rxneg input pins on the falling edge of the rxlineclk. for more information on this feature, please see section 7.1.2.1.3. bit 0?reframe (receive e3 framer) when a ?0? to ?1? transition is detected in this bit-field, then the receive e3 framer will be forced to start a frame search. 3.3.2.3 part number register 3.3.2.4 version number register 3.3.2.5 uni interrupt enable register address = 02h, part number register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 part number ro ro ro ro ro ro ro ro 0 0 0 0 0 0 1 1 address = 03h, version number register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 version number ro ro ro ro ro ro ro ro 0 0 0 0 0 0 1 1 address = 04h, uni interrupt enable register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused one sec interrupt enable tx e3 framer interrupt enable rx e3 framer interrupt enable tx cp interrupt enable rx cp interrupt enabl tx utopia interrupt enable rx utopia interrupt enable r/o r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 52 bit 6?one second interrupt enable this ?read/write? bit-field allows the user to enable or disable the ?one second? interrupt, that is automatically generated by the uni device, once for each second. writing a ?0? to this bit-field disables this interrupt. conversely, writing a ?1? to this bit-field enables the ?one- second? interrupt. bit 5?tx e3 framer interrupt enable this ?read/write? bit-field allows the user to disable the ?transmit e3 framer block? related interrupt, or to enable this interrupt, that has been enabled via the ?tx e3 lapd status/interrupt? register (address = 3fh). writing a ?0? to this bit-field disables the ?transmit e3 framer block? related interrupt (independent of the enable/ disable status of this interrupt within the ?tx e3 lapd status/interrupt? register). writing a ?1? to this bit-field enables this interrupt provided that it has already been enabled via the ?tx e3 lapd status/interrupt? register. bit 4?rx e3 framer interrupt enable this ?read/write? bit-field allows the user to globally disable all ?receive e3 framer? block interrupts; or to enable those ?receive e3 framer? interrupts that are enabled via ?rx e3 interrupt enable register-1? (address = 10h), or the ?rx e3 interrupt enable register -2? (address = 11h). writing a ?0? to this bit-field disables all ?receive e3 framer? block interrupts (independent of the enable/disable status of these interrupts within these other registers). writing a ?1? to this bit-field enables those ?receive e3 framer? interrupt that have already been enabled via these other registers. bit 3?tx cp interrupt enable this ?read/write? bit-field allows the user to disable the ?transmit cell processor block? related interrupt, or to enable this interrupt, that has been enabled via the ?tx cp control/interrupt? register (address = 72h). writing a ?0? to this bit-field disables the ?transmit cell processor block? related interrupt (independent of the enable/disable status of this interrupt within the ?tx cp control/interrupt? register). writing a ?1? to this bit-field enables this interrupt, provided it has been enabled within the ?tx cp control/interrupt? register. bit 5?rx cp interrupt enable this ?read/write? bit-field allows the user to globally disable all ?receive cell processor block? interrupts; or to enables those interrupts that have been enabled via the ?rx cp interrupt enable? register (address = 60h). writing a ?0? to this bit-field disables all ?receive cell processor block? interrupts (independent of the enable/ dis- able status of these interrupts via the ?rx cp interrupt enable? register). writing a ?1? to this bit-field enables those ?receive cell processor block? interrupt that have already been enabled via the ?rx cp interrupt enable? register. bit 1?tx utopia interrupt enable this ?read/write? bit-field allows the user to globally disable all ?transmit utopia interface block? interrupts; or to enable those interrupts that have been enabled via the ?tx utopia interrupt enable/status? register (address = 80h). writing a ?0? to this bit-field disables all ?transmit utopia interface block? interrupts (independent of the enable/disable status of these interrupts within the ?tx utopia interrupt enable/status? register). writing a ?1? to this bit-field enables those ?transmit utopia interface block? interrupts that have already been enabled via the ?tx utopia interrupt enable/status? register.
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 53 bit 0?rx utopia interrupt enable this ?read/write? bit-field allows the user to globally disable all ?receive utopia interface block? interrupts; or to enables those interrupts that have been enabled via the ?rx utopia interrupt enable/status? register (address = 7dh). writing a ?0? to this bit-field disables all ?receive utopia interface block? interrupts (independent of the enable/ disable status of these interrupts within the ?rx utopia interrupt enable/status? register). writing a ?1? to this bit- field enables those ?receive utopia interface block? interrupts that have already been enabled via the ?rx utopia interrupt enable/status? register. 3.3.2.6 uni interrupt status register bit 6?one second interrupt status this ?reset-upon-read? bit-field indicates whether or not the ?one second? interrupt has occurred, since the last read of this register. if this bit-field is ?0?, then a ?one second? interrupt has not occurred. however, if this bit-field is ?1?, then the ?one second? interrupt has occurred. bit 5? tx e3 (framer) interrupt status this ?read-only? bit-field indicates whether or not a ?transmit e3 framer block? interrupt request is pending. if this bit-field is ?0?, then no ?transmit e3 framer block? interrupt request is pending. however, if this bit-field is ?1?, then a ?transmit e3 framer? block interrupt request is pending and awaiting service. since the transmit e3 framer has one potential interrupt (lapd message transfer complete), the user should include a read to the tx e3 lapd status/interrupt register (address = 3fh), during the interrupt service routine, in order to properly service this interrupt. this bit-field will be cleared (set to ?0?) after the local m p has read the ?tx e3 lapd status/interrupt? register. bit 4?rx e3 (framer) interrupt status this ?read-only? bit field indicates whether or not a ?receive e3 framer block? interrupt request is pending. if this bit-field is ?0?, then no ?receive e3 framer block? interrupt request is pending. however, if this bit-field is ?1? then a ?receive e3 framer block? interrupt request is pending and awaiting service. since the receive e3 framer has several ?potential? interrupt sources, the user should include reads to the following reg- address = 05h, uni interrupt status register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused one sec interrupt status tx e3 framer interrupt enable rx e3 framer interrupt enable tx cp interrupt enable rx cp interrupt enable tx utopia interrupt enable rx utopia interrupt enable ro rur ro ro ro ro ro ro 0 0 0 0 0 0 0 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 54 isters, during the interrupt service routine, in order to determine the exact cause of the interrupt. ? rx e3 interrupt status register?1 (address = 12h) ? rx e3 interrupt status register?2 (address = 13h) this bit-field will be cleare d (set to ?0?) after the local m p has read the ?rx e3 interrupt status? register that contains the bit-field which is associated with the interrupting condition. bit 3?tx cp (cell processor) interrupt status this ?read-only? bit-field indicates whether or not a ?transmit cell processor block? interrupt is pending. if this bit-field is ?0?, then no ?transmit cell processor block? interrupt request is pending. however, if this bit-field is ?1?, then a ?transmit cell processor block? interrupt request is pending and awaiting ser- vice. since the transmit cell processor has only one potential interrupt source (data path integrity error occur- rence), the user should still include a read to the ?tx cp control/interrupt register (address = 72h), in the interrupt service routine, in order to properly service this interrupt. this bit-field will be cleared (set to ?0?) after the local m p has read the ?tx cp control/interrupt? register. bit 2?rx cp (cell processor) interrupt status this ?read-only? bit field indicates whether or not a ?receive cell processor block? interrupt request is pending. if this bit-field is ?0?, then no ?receive cell processor block? interrupt request is pending. however, if this bit-field is ?1? then a ?receive cell processor block? interrupt is pending and awaiting service. since the receive cell processor has several ?potential? interrupt sources, the user should include a read to the ?rx cp interrupt status? register (address = 61h), during the interrupt service routine, in order to determine the exact cause of the interrupt. this bit-field will be cleared (set to ?0?) after the local m p has read the ?rx cp interrupt status? register. bit 1?tx utopia interrupt status this ?read-only? bit field indicates whether or not a ?transmit utopia interface block? interrupt request is pending. if this bit-field is ?0?, then no ?transmit utopia interface block? interrupt request is pending. however, if this bit-field is ?1?, then a ?transmit utopia interface block? interrupt request is pending and awaiting service. since the transmit utopia interface block has multiple potential interrupt sources, the user should include a read to the ?tx utopia interrupt/status register? (address = 80h) in the interrupt service routine, in order to determine the exact cause of the interrupt. this bit-field will be cleared (set to ?0?) after the local m p has read the ?tx ut interrupt/status? register. bit 0?rx utopia interrupt status this ?read-only? bit field indicates whether or not a ?receive utopia interface block? interrupt request is pending. if this bit-field is ?0?, then no ?receive utopia interface block? interrupt request is pending. however, if this bit-field is ?1?, then a ?receive utopia interface block? interrupt request is pending and awaiting service. since the receive utopia interface block has multiple potential interrupt sources, the user should include a read to the ?rx ut interrupt enable/status register? (address = 7dh), in order to determine the exact cause of the interrupt. this bit-field will be cleared (set to ?0?) after the local m p has read the ?rx ut interrupt enable/status? register.
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 55 3.3.2.7 test cell control and status register bit 4?test cell (generator/receiver) enable this ?read/write? bit-field allows the user to perform some testing on the uni, by activating the ?test and diagnostic? section. once the user has activated this section, then the ?internal? test cell generator and test cell receiver will be active. the test cell generator will generate cells in accordance with a ?traffic pattern? as dictated by the user in his/her selection within the ?one shot test? bit field. the test cell generator will generate test cells that contain the header byte pattern, as specified (by the user) in the ?test cell header byte-1 through 4? registers. the payload portion of each of these test cells will be ?filled with? data generated by a pseudo-random byte sequence (prbs) generator. the test cell receiver functions as the ?test cell sink? and bit-error analyzer. the test cell receiver will recognize each of these test cells by their header byte patterns. further, the test cell receiver will attempt to analyze the payload data (within each of these test cells) by acquiring ?prbs lock? on the data. once the test cell receiver has ?prbs lock? on this test cell payload data, then it can perform error-checking and error-reporting on this data. the ?test and diagnostic? section of the uni performs error reporting by updating the ?test cell error accumulator? registers. writing a ?1? to this bit-field enables the ?test cell generator/receiver?. writing a ?0? disables the ?test cell generator/rece iver?. for more information on these features, please see section 4.3. bit 2?one shot test this ?read/write? bit-field allows the user to specify which of two ?traffic options? that he/she would like the test cells to be generated. the uni ?test and diagnostic? section supports the following traffic options: ? ?one shot? mode?a single burst of 1024 test cells are generated ? ?continuous? mode?a continuous stream of test cells are generated for the duration that the ?test cell generator/ receiver? receiver are enabled. setting this bit-field to ?1?, followed by a ?0? to ?1? transition in the ?test cell enable? bit field (bit 4 of this register), causes the test cell generator to operate in the ?one shot? mode, and generate a single burst of 1024 test cells. afterwards the test cell generator will halt, and will cease the production of new test cells, until the next ?0? to ?1? transition occurs in the ?test cell enable? bit field. conversely, setting this bit-field to ?0?, followed by a ?0? to ?1? transition in the ?test cell enable? bit field, causes thetest cell generator to operate in the ?continuous? mode. when the test cell generator is operating in the ?continuous? mode, it will produce a ?continuous? stream of test cells, for the duration that the ?test cell enable? bit-field is set to ?1?. bit 1?one shot done this ?read-only? bit-field allows the user to monitor the status of the test cell generator, while it is operating in the ?one shot? mode. this bit-field will be set to ?1?, when the test cell generator has completed its generator of the ?burst? of the 1024 test cells. conversely, this bit-field will be set to ?0? while ?test cell generation? is ?in process?. note: this bit-field has no meaning if the test cell generator is operating in the ?continuous? mode. address = 06h, test cell control and status register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused test cell enable unused one shot test one shot done prbs lock ro ro ro r/w ro r/w ro ro 0 0 0 0 0 0 0 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 56 bit 0?prbs (pseudo-random byte sequence) lock this ?read-only? bit field indicates whether or not the ?test cell receiver? has acquired ?prbs lock? with the payload data of the incoming test cells. once the ?test cell receiver? has acquired ?prbs lock? with this data, then it can begin to perform error-checking on the incoming test cells. 3.3.2.9 test cell header byte-1 the ?read/write? bit-fields, within this register; along with those bit-fields within the ?test cell header byte-2 through - 4? registers; allows the user to define the header byte patterns for each of the ?test cells? that will be generated by the test cell generator. this particular register allows the user to define the pattern for the first octet of these test cells. 3.3.2.10 test cell header byte-2 the ?read/write? bit-fields, within this register; along with those bit-fields within the ?test cell header byte-1, -3 and -4? registers; allows the user to define the header byte patterns for each of the ?test cells? that will be generated by the test cell generator. this particular register allows the user to define the pattern for the second octet of these test cells. 3.3.2.11 test cell header byte-3 address = 07h, future use bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 address = 08h, test cell header byte-1 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 test cell header byte 1 r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 1 0 0 0 1 address = 09h, test cell header byte-2 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 test cell header byte 2 r/w r/w r/w r/w r/w r/w r/w r/w 0 0 1 0 0 0 1 0 address = 0ah, test cell header byte-3 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 test cell header byte 3
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 57 the ?read/write? bit-fields, within this register; along with those bit-fields within the ?test cell header byte -1, -2 and -4? registers; allows the user to define the header byte patterns for each of the ?test cells? that will be generated by the test cell generator. this particular register allows the user to define the pattern for the third octet of these test cells. 3.3.2.12 test cell header byte-4 the ?read/write? bit-fields, within this register; along with those bit-fields within the ?test cell header byte-1 through -3 ? registers; allows the user to define the header byte patterns for each of the ?test cells? that will be generated by the test cell generator. this particular register allows the user to define the pattern for the fourth octet of these test cells. 3.3.2.13 test cell error accumulator?msb these ?reset-upon-read? bit fields, along with those ofthe ?test cell error accumulator?lsb? register (address = 0dh), contains a 16-bit representation of the number of erred test cells that have been detected by the ?test cell receiver? since the last read of these registers. this register contains the upper-byte value for this 16-bit expression. note: the contents of these registers are valid only if the test cell receiver has acquired ?prbs lock? with the payload data of the test cells that it has received. 3.3.2.13 test cell error accumulator?lsb r/w r/w r/w r/w r/w r/w r/w r/w 0 0 1 1 0 0 1 1 address = 0bh, test cell header byte-4 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 test cell header byte 4 r/w r/w r/w r/w r/w r/w r/w r/w 0 1 0 0 0 1 0 0 address = 0ch, test cell error accumulator?msb bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 test cell error?high byte rur rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0 address = 0dh, test cell error accumulator?lsb bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 test cell error?low byte address = 0ah, test cell header byte-3
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 58 these ?reset-upon-read? bit fields, along with those ofthe ?test cell error accumulator?msb? register (address = 0ch), contains a 16-bit representation of the number of erred test cells that have been detected by the ?test cell receiver? since the last read of these registers. this register contains the lower-byte value for this 16-bit expression. note: the contents of these registers are valid only if the test cell receiver has acquired ?prbs lock? with the payload data of the test cells that it has received. 3.3.2.15?rx e3 configuration and status register-1 bit 7?5?rxpldtype[2:0] (received payload type[2:0]) these three ?read-only? bit-fields contain the ?payload type? value within the ma byte of the most recently received e3 frame. note: the ?payload type mismatch? interrupt will be generated if the contents of these bit-fields differ from that of the ?expected payload types? in bits 2 through 0 within this register. bit 4?rxferf algo this ?read/write? bit-field allows the user to select one of the two rxferf declaration algorithms: writing a ?0? to this bit-field selects the following ?rxferf declaration? algorithm: ? the receive e3 framer declares a ?far end receive failure? (ferf) if the ?ferf? bit-field, within the ma byte is set to ?1? for 3 consecutive incoming e3 frames. likewise, the receive e3 framer will negate the ?far end receive failure? condition if the ?ferf? bit-field, within the ma byte is set to ?0? for 3 consecutive incoming e3 frames. writing a ?1? to this bit-field selects the following ?rxferf declaration? algorithm: ? the receive e3 framer declares a ?far end receive failure? (ferf) if the ?ferf? bit-field, within the ma byte is set to ?1? for 5 consecutive e3 frames. likewise, the receive e3 framer will negate the ?far end receive failure? condition if the ?ferf? bit-field, within the ma byte is set to ?0? for 5 consecutive incoming e3 frames. bit 3?rx tmark algorithm this ?read/write? bit-field allows the user to select the number of consecutive incoming e3 frames, that the ?timing marker? bit-field (within the ma byte-field) must be of a given logic state, before it is ?validated? by the receive e3 framer. once the receive e3 framer has ?validated? the state of the ?timing marker? bit-field, then it will write this logic state into bit 1 (rxtmark) within the ?rx e3 configuration & status register (address = 0fh). rur rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0 address = 0eh, rx e3 configuration and status register-1 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rxpldtype[2:0] rxferf algo rxtmark algo rxpldexp[2:0] ro ro ro r/w r/w r/w r/w r/w 0 0 0 1 0 0 0 0 address = 0dh, test cell error accumulator?lsb
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 59 writing a ?0? into this bit-field causes the receive e3 framer to ?validate? the timing marker value after receiving 3 consecutive incoming e3 frames, with the ?timing marker? bit-field of a given value. writing a ?1? into this bit-field causes the receive e3 framer to validate the ?timing marker? value after receiving 5 consecutive incoming e3 frames, with the ?timing marker? bit-field of a given value. bits 2?0: rxpldexp[2:0] this ?read/write? bit-field allows the user to specify the ?payload type? that he/she expects in the ma bytes, of each incoming e3 frame. if the receive e3 framer detects a ?payload type? that differs from the values within these bit-fields, then the uni will generate the ?payload type mismatch? interrupt. 3.3.2.17 rx e3 status and configuration register-2 bit 7?rxlof algo (loss of frame declaration algorithm) this ?read/write? bit-field allows the user to select the ?lof? (loss of frame) declaration criteria, that will be used by the receive e3 framer. writing a ?0? to this bit-field configures the receive e3 framer to declare an lof condi- tion, after it has been in the oof condition for 24 frame periods (3 ms). writing a ?1? to this bit-field configures the receive e3 framer to declare an lof condition, after it has been in the oof condition for 8 frame periods (1 ms). bit 6?rxlof (loss of frame declaration) this ?read-only? bit-field indicates whether or not the receive e3 framer is currently in the ?loss of frame? (lof) condition. if this bit-field is set to ?1?, then the receive e3 framer is currently in the lof condition. conversely, if this bit-field is set to ?0?, then the receive e3 framer is currently not in the lof condition. bit 5?rxoof (out of frame declaration) this ?read-only? bit field indicates whether or not the receive e3 framer is currently experiencing an ?out of frame? (oof) condition. the receive e3 framer will declare an oof condition if it has detected errors in the frame alignment bytes (fa1 and fa2) in four consecutive frames. if this bit-field is set to ?1?, then the receive e3 framer has declared, and is continuing to experience an oof condition. if this bit-field is set to ?0?, then the receive e3 framer is currently not experiencing an oof condition. bit 4?rxlos (loss of signal declaration) this ?read-only? bit-field indicates whether or not the receive e3 framer is currently experiencing a ?loss of signal? (los) condition. the receive e3 framer will declare an los condition if it has detected a string of 32 consecutive ?0s?, via the rxpos and rxneg input pins. if this bit-field is set to ?1?, then the receive e3 framer has declared, and is continuing to experience an los condition. if this bit-field is set to ?0?, then the receive e3 framer is currently not experiencing an los condition. address = 0fh, rx e3 configuration and status register-2 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rxlof algo rxlof rxoof rxlos rxais rxpld type unstab rx tmark rxferf rw ro ro ro ro ro ro ro 0 1 1 0 0 1 1 1
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 60 bit 3?rxais (alarm indication status declaration) this ?read-only? bit-field indicates whether or not the receive e3 framer is currently experiencing an ?ais? condition. the receive e3 framer will declare an ais condition if it has detected two consecutive e3 frames, that each contain less than seven (7) ?0s? . if this bit-field is set to ?1?, then the receive e3 framer has declared, and is continuing to expe- rience an ais condition. if this bit-field is set to ?0?, then the receive e3 framer is currently not experiencing an ais condition. bit 2?rxpldtype unstab this ?read-only? bit-field indicates whether or not the receive e3 framer has been receiving a consistent ?payload type? value (within the ma byte-field); in the last 5 consecutive incoming e3 frames. if the receive e3 framer has detected a change in the ?payload type? value, within the last 5 incoming e3 frames, then it will set this bit-field to ?1?. if the ?payload type? value has been consistent in the last 5 e3 frames, then the receive e3 framer will set this bit-field to ?0?. bit 1?rx tmark this ?read-only? bit-field reflects the ?most recently? validated ?timing marker? value. the receive e3 framer will validate the ?timing marker? state, after it has detected a ?user-selectable? number of consecutive incoming e3 frames with a consistent ?timing marker? value. the user makes this selection by writing the appropriate value to bit 3 (rxt- markalgo) within the ?rx e3 configuration/status register (address = 0eh). bit 0?rxferf (far end receive failure) this ?read-only? bit-field indicates whether or not the receive e3 framer is experiencing an ?ferf? (far-end- receive-failure) condition. the receive e3 framer willdeclare a ?ferf? condition, if it has received a ?user-selectable? number of consecutive e3 frames, with the ferf bit-field (within the ma byte) set to ?1?. this ?user-selectable? number is either 3 or 5 e3 frames. conversely, the receive e3 framer will ?negate? the ferf declaration, if it has received this ?user-selectable? number of consecutive e3 frames, with the ferf bit-field set to ?0?. if this bit-field is set to ?1?, then the receive e3 framer has declared an ferf condition. if this bit-field is set to ?0?, then the receive e3 framer has not declared an ferf condition. please see sections 6.3.3.3.1 and 7.1.2.3.3, for a more detailed discussion on the meaning of the ferf bit-field, within the e3 frame. 3.3.2.18 rx e3 interrupt enable register-1 bit 4?change of frame alignment interrupt enable this ?read/write? bit-field allows the user to enable or disable the ?change of frame alignment? interrupt. setting this bit-field to ?1? enables this interrupt. setting this bit-field to ?0? disables this interrupt. bit 3?oof (out of frame) interrupt enable this ?read/write? bit field allows the user to enable or disable the ?change in out-of-frame (oof) status? interrupt. address = 10h, rx e3 interrupt enable register-1 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused cofa interrupt enable oof interrupt enable lof interrupt enable los interrupt enable ais interrupt enable ro ro ro r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 61 setting this bit-field to ?1? enables this interrupt. setting this bit-field to ?0? disables this interrupt. for more infor- mation on the ?oof? condition, please see section 7.1.2.2.1. bit 2?lof (loss of frame) interrupt enable this ?read/write? bit-field allows the user to enable ordisable the ?change in loss-of-frame (lof) status? interrupt. setting this bit-field to ?1? enables this interrupt. setting this bit-field to ?0? disables this interrupt. for more information on the ?lof? condition, please seesection 7.1.2.2.1. bit 1?los (loss of signal) interrupt enable this ?read/write? bit-field allows the user to enable or disable the ?change in los condition? interrupt. setting this bit-field to ?1? enables this interrupt. setting this bit-field to ?0? disables this interrupt. for more information on the los condition, please see section 7.1.2.3.1. bit 0?ais interrupt enable this ?read/write? bit-field allows the user to enable or disable the ?change in ais condition? interrupt. setting this bit-field to ?1? enables this interrupt. setting this bit-field to ?0? disables this interrupt. for more information on the ais condition, please see section 7.1.2.3.2. 3.3.2.19 rx e3 interrupt enable register-2 bit 6?ttb change interrupt enable this ?read/write? bit-field allows the user to enable ordisable the ?change in trail trace buffer message? inter- rupt. setting this bit-field to ?1? enables this interrupt. setting this bit-field to ?0? disables this interrupt. for more infor- mation on trail trace buffer messages, please see section 7.1.2.7. bit 5?received lapd message interrupt enable this ?read/write? bit-field allows the user to enable or disable the ?received lapd message frame? interrupt. setting this bit-field to ?1? enables this interrupt. setting this bit-field to ?0? disables this interrupt. for more infor- mation on this interrupt, please see section 7.1.2.9.10. bit 4?febe (far-end block error) interrupt enable this ?read/write? bit-field allows the user to enable or disable the ?far-end-block error (febe)? interrupt. setting this bit-field to ?1? enables this interrupt. setting this bit-field to ?0? disables this interrupt. for more information on the ?febe? interrupt condition, please see section 7.1.2.9.11. bit 3?ferf (far-end receive failure) interrupt enable this ?read/write? bit-field allows the user to enable or disable the ?change in ferf condition? interrupt. setting this bit-field to ?1? enables this interrupt. setting this bit-field to ?0? disables this interrupt. for more information on the ?change in ferf condition? interrupt, please see section 7.1.2.3.3. bit 2?em byte error interrupt enable this ?read/write? bit-field allows the user to enable or disable the ?em byte error? interrupt. setting this bit-field to address = 11h, rx e3 interrupt enable register-2 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused ttb change interrupt enable lapd interrupt enable febe interrupt enable ferf interrupt enable em-byte error interrupt enable framing byte error interrupt enable rx pld mis interrupt enable ro r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 62 ?1? enables this interrupt. setting this bit-field to ?0? disables this interrupt. for more information on this interrupt, please see section 7.1.2.9.5. bit 1?framing byte error interrupt enable this ?read/write? bit-field allows the user to enable or disable the ?framing byte error? interrupt. setting this bit- field to ?1? enables this interrupt. setting this bit-field to ?0? disables this interrupt. for more information on this inter- rupt, please see section 7.1.2.9.12. bit 0?receive payload type mismatch interrupt enable this ?read/write? bit-field allows the user to enable or disable the ?receive payload type mismatch? interrupt. set- ting this bit-field to ?1? enables this interrupt. setting this bit-field to ?0? disables this interrupt. for more information on this interrupt, please see section 7.1.2.9.9. 3.3.2.20 rx e3 interrupt status register-1 bit 4?cofa (change of frame alignment) interrupt status this ?reset-upon-read? bit-field will be set to ?1? if the ?change of frame alignment? interrupt has occurred since the last read of this register. the receive e3 framer will generate the ?change of frame alignment? interrupt if it has detected a change in frame alignment; in the incoming e3 frames. bit 3?oof (receive e3 framer) interrupt status this ?reset upon read? bit-field is set to ?1? if the receive e3 framer has detected a ?change in the out-of-frame (oof) condition?, since the last time this register was read. therefore, this bit-field will be asserted under either of the follow- ing two conditions: 1. when the receive e3 framer has detected the appropriate conditions to declare an ?oof? condition. 2. when the receive e3 framer has transitioned from the ?oof? condition (frame acquisition mode) into the ?in-frame? condition (frame maintenance mode). for more information of the oof condition, please see section 7.1.2.2.1. bit 2?lof (loss of frame) interrupt status this ?reset-upon-read? bit-field will be set to ?1? if a ?change in lof condition? interrupt has occurred since the last address = 12h, rx e3 interrupt status register-1 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused cofa interrupt status oof interrupt status lof interrupt status los interrupt status ais interrupt status ro ro ro rur rur rur rur rur 0 0 0 0 0 0 0 0
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 63 read of this register. the receive e3 framer will generate the ?change in lof condition? interrupt is response to either of the following two occurrences. 1. whenever the receive e3 framer transitions from the ?oof condition? state into the ?lof condition? state, within the ?e3 framing acquisition/maintenance? algorithm (per figure 60). 2. whenever the receive e3 framer transitions from t he ?fa1, fa2 octet verification? state to the ?in-frame? state, within the ?e3 framing acquisition/maintenance? algorithm (per figure 60). bit 1?los (loss of signal) interrupt status this ?reset upon read? bit will be set to ?1?, if the receive e3 framer has detected a ?change in the los status? condition, since the last time this register was read. this bit-field will be asserted under either of the following two conditions: 1. when the receive e3 framer detects the occurrence of an los condition (e.g., the occurrence of 32 consecu- tive ?spaces? in the incoming e3 data stream), and 2. when the receive e3 framer detects the end of an los condition (e.g., when the receive e3 framer detects a string 32 bits that does not contain a string of four consecutive ?0s?). the local m p can determine the current state of the los condition by reading bit 6 of the ?rx e3 configuration and status? register (address = 0eh). for more information in the ?los of signal (los) alarm, please see section 7.1.2.3.1. bit 0?ais interrupt status this ?reset upon read? bit field will be set to ?1?, if the receive e3 framer has detected a ?change in the ais? con- dition, since the last time this register was read. this bit-field will be asserted under either of the following two conditions: 1. when the receive e3 framer first detects an ais condition in the incoming bit 4?idle condition interrupt status, and 2. when the receive e3 framer has detected the end of an ?ais condition?. the local m p can determine the current state of the ais condition by reading bit 7 of the ?rx e3 configuration and status? register (address = 0eh). for more information on the ?ais condition? please see section 7.1.2.3.2. 3.3.2.21 rx e3 interrupt status register-2 bit 6? ttb change interrupt status (receipt of new trail trace buffer message interrupt) this ?reset-upon-read? bit-field will be set to ?1? if a ?receipt of new trail trace buffer message? interrupt has occurred since the last read of this register. the receive e3 framer will generate the ?receipt of new trail trace buffer message? interrupt, if it receives an address = 13h, rx e3 interrupt status register-2 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unuse d ttb change interrupt status lapd interrupt status febe interrupt status ferf interrupt status em-byte error inter- rupt status framing byte error interrupt status rx pld mis interrupt status ro rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 64 e3 frame in which the value of the tr byte-field is of the form ?1xxxxxxxb?. a tr byte-field value of this form is iden- tified as the ?frame start marker?. please see section 7.1.2.9.8 for a more detailed discussion of this interrupt. bit 5?received lapd message interrupt status this ?reset-upon-read? bit-field will be set to ?1? if the ?receipt of new lapd message frame? interrupt has occurred since the last read of this register. the receive e3 framer will generate this ?receipt of new lapd message frame? interrupt when the lapd receiver has received a complete lapd message frame from the ?far-end? lapd transmitter. please see section 7.1.2.9.10 for a more detailed discussion of this interrupt. bit 4?febe (far-end block error) interrupt status this ?reset-upon-read? bit-field will be set to ?1? if the ?febe? (far-end-block error) interrupt has occurred since the last read of this register. the receive e3 framer will generate the ?febe? interrupt anytime it detects a ?1? in the febe bit-field within an incoming e3 frame. please see section 7.1.2.9.11 for a more detailed discussion of this interrupt. bit 3?ferf interrupt status this ?reset upon read? bit will be set to ?1? if the receive e3 framer has detected a ?change in the rxferf? condition, since the last time this register was read. this bit-field will be asserted under either of the following two conditions. 1. when the receive e3 framer first detects the occurrence of an rx ferf condition (all x-bits are set to ?0?). 2. when the receive e3 framer detects the end of the rx ferf condition (all x-bits are set to ?0?). for more information on the rx ferf (yellow alarm) condition, please see section 7.1.2.3.3. bit 2?em (bip-8) byte error interrupt status this ?reset-upon-read? bit-field will be set to ?1? if the ?bip-8 error? interrupt has occurred since the last read of this register. the receive e3 framer will generate the ?bip-8 error? interrupt if it has concluded that it has received an errored e3 frame, from the ?far-end? terminal. please see section 7.1.2.9.5 for a more detailed discussion of this interrupt. bit 1?framing byte error interrupt status this ?reset-upon-read? bit-field will be set to ?1? if the ?framing byte error? interrupt has occurred since the last read of this register. the receive e3 framer will generate the ?framing byte error? interrupt if it has detected an error in the fa1 or fa2 bytes, on an incoming e3 frame. please see section 7.1.2.9.12 for a more detailed discussion of this interrupt. bit 0?rx pld mis interrupt status this ?reset-upon-read? bit-field will be set to ?1? if the ?payload type mismatch? interrupt has occurred since the last read of this register. the receive e3 framer will generate the ?payload type mismatch? interrupt when it detects that the values, within the payload type bit-fields of the incoming e3 frame, has changed from that of the previous e3 frame. please see
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 65 section 7.1.2.9.9 for a more detailed discussion on this interrupt. 3.3.2.22 rx nr byte register this ?read-only? register contains the value of the nr byte, within the most recently received e3 frame. please see section 6.3.2.1.5 for a more detailed discussion on this register. 3.3.2.23 rx gc byte register this ?read-only? register contains the value of the gc byte, residing in the most recently received e3 frame. 3.3.2.24 rx ttb-0 register this ?read-only? register contains the ?frame start marker? byte of the 16 byte trail trace buffer message that has been received from the ?far-end? terminal, via the tr byte-field within the incoming e3 frames. the remaining bytes, of this trail trace buffer message can be found in the ?rx ttb-1? through ?rx ttb-15? registers. the data in this register is typically of the form [1, c6, c5, c4, c3, c2, c1, c0]. the ?1? in the msb position identifies this byte as being the ?frame start marker? (e.g., the first byte within the 16 byte trail trace buffer message). the remaining bits: c0?c6 contain the crc-7 value that was calculated over the previous 16 byte trail trace buffer message. address = 14h, rx nr byte register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx nr byte ro ro ro ro ro ro ro ro 0 0 0 0 0 0 0 0 address = 15h, rx gc byte register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx gc byte register ro ro ro ro ro ro ro ro 0 0 0 0 0 0 0 0 address = 16h, rx ttb-0 register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 receive trail trace byte-0 ro ro ro ro ro ro ro ro 0 0 0 0 0 0 0 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 66 note: the XR-T7234 e3 uni will not compute or verify this crc-7 value. it is up to the user?s hardware and/or soft- ware to compute and verify this value. for more information on the use of this register, please see section 7.1.2.7. 3.3.2.25 rx ttb-1 register this ?read-only? register contains the second (2nd) byte within the 16 byte trail trace buffer message, that has been received from the ?far-end? terminal. this register typical contains an ascii character that is required for the e.164 numbering format. for more information on the use of this register, please see section 7.1.2.7. 3.3.2.26 rx ttb-2 register this ?read-only? register contains the third (3rd) byte within the 16 byte trail trace buffer message, that has been received from the ?far-end? terminal. this register typical contains an ascii character that is required for the e.164 numbering format. for more information on the use of this register, please see section 7.1.2.7. 3.3.2.27 rx ttb-3 register this ?read-only? register contains the fourth (4th) byte within the 16 byte trail trace buffer message, that has been address = 17h, rx ttb-1 register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 receive trail trace byte-1 ro ro ro ro ro ro ro ro 0 0 0 0 0 0 0 0 address = 18h, rx ttb-2 register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 receive trail trace byte-2 ro ro ro ro ro ro ro ro 0 0 0 0 0 0 0 0 address = 19h, rx ttb-3 register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 receive trail trace byte-3 ro ro ro ro ro ro ro ro 0 0 0 0 0 0 0 0
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 67 received from the ?far-end? terminal. this register typical contains an ascii character that is required for the e.164 numbering format. for more information on the use of this register, please see section 7.1.2.7. 3.3.2.28 rx ttb-4 register this ?read-only? register contains the fifth (5th) byte within the 16 byte trail trace buffer message, that has been received from the ?far-end? terminal. this register typical contains an ascii character that is required for the e.164 numbering format. for more information on the use of this register, please see section 7.1.2.7. 3.3.2.29 rx ttb-5 register this ?read-only? register contains the sixth (6th) byte within the 16 byte trail trace buffer message, that has been received from the ?far-end? terminal. this register typical contains an ascii character that is required for the e.164 numbering format. for more information on the use of this register, please see section 7.1.2.7. 3.3.2.30 rx ttb-6 register this ?read-only? register contains the seventh (7th) byte within the 16 byte trail trace buffer message, that has been received from the ?far-end? terminal. this register typical contains an ascii character that is required for the e.164 numbering format. for more information on the use of this register, please see section 7.1.2.7. address = 1ah, rx ttb-4 register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 receive trail trace byte-4 ro ro ro ro ro ro ro ro 0 0 0 0 0 0 0 0 address = 1bh, rx ttb-5 register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 receive trail trace byte-5 ro ro ro ro ro ro ro ro 0 0 0 0 0 0 0 0 address = 1ch, rx ttb-6 register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 receive trail trace byte-6 ro ro ro ro ro ro ro ro 0 0 0 0 0 0 0 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 68 3.3.2.31 rx ttb-7 register this ?read-only? register contains the eighth (8th) byte within the 16 byte trail trace buffer message, that has been received from the ?far-end? terminal. this register typical contains an ascii character that is required for the e.164 numbering format. for more information on the use of this register, please see section 7.1.2.7. 3.3.2.32 rx ttb-8 register this ?read-only? register contains the ninth (9th) byte within the 16 byte trail trace buffer message, that has been received from the ?far-end? terminal. this register typical contains an ascii character that is required for the e.164 numbering format. for more information on the use of this register, please see section 7.1.2.7. 3.3.2.33 rx ttb-9 register this ?read-only? register contains the tenth (10th) byte within the 16 byte trail trace buffer message, that has been received from the ?far-end? terminal. this register typical contains an ascii character that is required for the e.164 numbering format. for more information on the use of this register, please see section 7.1.2.7. address = 1dh, rx ttb-7 register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 receive trail trace byte-7 ro ro ro ro ro ro ro ro 0 0 0 0 0 0 0 0 address = 1eh, rx ttb-8 register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 receive trail trace byte-8 ro ro ro ro ro ro ro ro 0 0 0 0 0 0 0 0 address = 1fh, rx ttb-9 register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 receive trail trace byte-9 ro ro ro ro ro ro ro ro 0 0 0 0 0 0 0 0
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 69 3.3.2.34 rx ttb-10 register this ?read-only? register contains the eleventh (11th) byte within the 16 byte trail trace buffer message, that has been received from the ?far-end? terminal. this register typical contains an ascii character that is required for the e.164 numbering format. for more information on the use of this register, please see section 7.1.2.7. 3.3.2.35 rx ttb-11 register this ?read-only? register contains the twelfth (12th) byte within the 16 byte trail trace buffer message, that has been received from the ?far-end? terminal. this register typical contains an ascii character that is required for the e.164 numbering format. for more information on the use of this register, please see section 7.1.2.7. 3.3.2.36 rx ttb-12 register this ?read-only? register contains the thirteenth (13th) byte within the 16 byte trail trace buffer message, that has been received from the ?far-end? terminal. this register typical contains an ascii character that is required for the e.164 numbering format. for more information on the use of this register, please see section 7.1.2.7. address = 20h, rx ttb-10 register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 receive trail trace byte-10 ro ro ro ro ro ro ro ro 0 0 0 0 0 0 0 0 address = 21h, rx ttb-11 register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 receive trail trace byte-11 ro ro ro ro ro ro ro ro 0 0 0 0 0 0 0 0 address = 22h, rx ttb-12 register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 receive trail trace byte-12 ro ro ro ro ro ro ro ro 0 0 0 0 0 0 0 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 70 3.3.2.37 rx ttb-13 register this ?read-only? register contains the fourteenth (14th) byte within the 16 byte trail trace buffer message, that has been received from the ?far-end? terminal. this register typical contains an ascii character that is required for the e.164 numbering format. for more information on the use of this register, please see section 7.1.2.7. 3.3.2.38 rx ttb-14 register this ?read-only? register contains the fifteenth (15th) byte within the 16 byte trail trace buffer message, that has been received from the ?far-end? terminal. this register typical contains an ascii character that is required for the e.164 numbering format. for more information on the use of this register, please see section 7.1.2.7. 3.3.2.39 rx ttb-15 register this ?read-only? register contains the sixteenth (16th) byte within the 16 byte trail trace buffer message, that has been received from the ?far-end? terminal. this register typical contains an ascii character that is required for the e.164 numbering format. for more information on the use of this register, please see section 7.1.2.7. address = 23h, rx ttb-13 register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 receive trail trace byte-13 ro ro ro ro ro ro ro ro 0 0 0 0 0 0 0 0 address = 24h, rx ttb-14 register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 receive trail trace byte-14 ro ro ro ro ro ro ro ro 0 0 0 0 0 0 0 0 address = 25h, rx ttb-15 register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 receive trail trace byte-15 ro ro ro ro ro ro ro ro 0 0 0 0 0 0 0 0
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 71 3.3.2.40 rx e3 lapd control register bit 1?dl from nr this ?read/write? bit-field allows the user to specify whether the lapd receiver should retrieve the bytes, comprising the incoming lapd message frame, from the nr byte-field, or from the gc byte-field, within each incoming e3 frame. writing a ?1? configures the lapd receiver to retrieve the incoming lapd message frame octets from the nr byte-field, within each incoming e3 frame. writing a ?0? configures the lapd receiver to retrieve the incoming lapd message frame octets from the gc byte. bit 0?rxlapd enable this ?read/write? bit-field allows the user to enable or disable the lapd receiver, for reception of incoming lapd message frames from the ?far-end? lapd transmitter. writing a ?1? to this bit-field enables the lapd receiver. writing a ?0? to this bit-field disables the lapd receiver. 3.3.2.41 rx e3 lapd status register bit 6?rx abort this ?read-only? bit-field indicates whether or not the lapd receiver is currently detecting an abort sequence (e.g., a string of 7 consecutive ?1s?). this bit-field is set to ?1? if the lapd receiver is currently detecting an abort sequence in the incoming lapd channel. conversely, this bit-field is set to ?0? if the lapd receiver has not detected an abort sequence, since the last read of this register. bit 5, 4?rxlapd type[1:0] these two ?read-only? bit-fields combine to indicate the type and size of lapd message frame that has been address = 26h, rx e3 lapd control register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused dl from nr rxlapd enable ro ro ro ro ro ro r/w r/w 0 0 0 0 0 0 0 0 address = 27h, rx e3 lapd status register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused rx abort rxlapd type[1:0] rx cr type rx fcs error endof message flag present ro ro ro ro ro ro ro ro 0 0 0 0 0 0 0 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 72 received by the lapd receiver. the following table relates the contents of these bit-fields to the lapd message type/size. bit 3?rx cr type this ?read-only? bit-field indicates the state of the c/r bit-field, within octet # 2 of the most recently received lapd message frame. bit 2?rx fcs error this ?read-only? bit-field indicates whether or not the lapd receiver has detected an fcs (frame check sequence) error, in the most recently received lapd message frame. this bit-field is set to ?0? if the lapd receiver does not detect an fcs error in this lapd message frame. conversely, this bit-field is set to ?1? if the lapd receiver does detect an fcs error in this lapd message frame. for a more detailed discussion on the lapd receiver?s handling of the fcs bytes, please see section 7.1.2.5. bit 1?endofmessage the lapd receiver will assert this ?read-only? bit-field, when it has received a complete lapd message frame. this bit-field, along with the ?receipt of new lapd message frame? interrupt, serves to inform the local m p that the ?receive lapd message? buffer contains a new pmdl message that needs to be read and processed. this bit-field is cleared (to ?0?) upon reading this register. bit 0?flag present the lapd receiver will assert this ?read-only? bit-field when it is currently detecting the flag sequence octet (7eh) in the incoming lapd channel (e.g., either the gc or the nr byte-field, within each e3 frame). the lapd receiver will negate this bit-field when it is no longer receiving the flag sequence octet in the incoming lapd channel. 3.3.2.42 tx e3 configuration register bit 7?auto retransmit this ?read/write? bit-field allows the user to configure the lapd transmitter to either transmit the lapd message frame only once; or repeatedly at one-second intervals. writing a ?0? to this bit-field configures the lapd transmitter to transmit the lapd message frame once. afterwards, rxlapdtype[1:0] lapd message frame type pmdl message size (information section) 00 test signal identification type 76 bytes 01 idle signal identification type 76 bytes 10 cl path identification type 76 bytes 11 itu-t path identification type 82 bytes address = 28h, tx e3 configuration register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 auto re-transmit txlapd type[1:0] dlinnr nodata link txais enable txlos enable marx r/w r/w r/w r/w r/w r/w r/w r/w 1 0 0 0 1 0 0 1
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 73 the lapd transmitter will halt transmission, until it has commanded to transmit another lapd message frame. writing a ?1? to this bit-field configures the lapd transmitter to transmit the lapd message frame repeatedly at one second intervals. in this configuration, the lapd transmitter will repeat its transmission of the lapd message frame until it has been disabled. bit 6, 5?txlapd type[1:0] these two ?read/write? bit-fields allow the user to specify the type and size of lapd message frame that he/ she wishes to transmit to the ?far end? lapd receiver. the following table relates the contents of these bit- fields to the lapd message frame type. bit 4?dlinnr this ?read/write? bit-field allows the user to specify whether the lapd transmitter should insert the ?out- bound? lapd message frame octets into the nr byte-field, or in the gc-byte-field, within each outbound e3 frame. writing a ?1? configures the lapd transmitter to insert the octets of the outbound lapd message frame into the nr byte-field, within each outbound e3 frame. writing in ?0? configures the lapd transmitter to insert the octets of the outbound lapd message frame into the gc byte-field, within each outbound e3 frame. bit 3?no data link (lapd transmitter enable/disable) this ?read/write? bit-field allows the user to enable or disable the lapd transmitter. writing a ?1? to this bit-field causes the lapd transmitter to be disabled, and to not insert any outbound lapd mes- sage frame octets into the nr or gc byte-fields of the outbound e3 frames. conversely, writing a ?0? to this bit- field enables the lapd transmitter, for transmission of any outbound lapd message frames. bit 2?txais enable this ?read/write? bit-field allows the user to command the transmit e3 framer to transmit an ais pattern, upon demand. writing a ?0? to this bit-field allows the transmit e3 framer to transmit internally generated data (e.g., the itu-t g.832 compatible e3 frames with atm cell data) to the ?far-end? terminal. writing a ?1? to this bit-field causes the transmit e3 framer to transmit an all ?1s? pattern to the ?far-end? terminal. note: if the transmit e3 framer is transmitting an ais pattern to the ?far-end? terminal, then it is not transmit- ting any e3 frames or atm cell data. consequently, if this command is invoked, the ?far end? terminal will experience an ?oof? (out of frame) and an ?lcd? (loss of cell delineation) condition. bit 1?txlos enable this ?read/write? bit-field allows the user to command the transmit e3 framer to transmit an los pattern, upon demand. writing a ?0? to this bit-field allows the transmit e3 framer to transmit internally generated data (e.g., the itu-t g.832 compatible e3 frames with atm cell data) to the ?far-end? terminal. writing a ?1? to this bit-field causes the transmit e3 framer to transmit an ?all 0s? pattern to the ?far-end? terminal. note: if the transmit e3 framer is transmitting an los pattern to the far-end terminal, then it is not transmit- ting any e3 frames or atm cell data. consequently, the ?far-end? terminal will experience an ?los? (loss of signal), ?oof? (out of frame), and an ?lcd? (loss of cell delineation) condition. txlapdtype[1:0] lapd message frame type pmdl message size (information section) 00 test signal identification type 76 bytes 01 idle signal identification type 76 bytes 10 cl path identification type 76 bytes 11 itu-t path identification type 82 bytes
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 74 bit 0 - marx (ferf and febe bit-field loopback) this ?read/write? bit-field allows the user to specify whether the value of the ferf and febe bit-fields, in the ?out- bound? e3 frames; should be based upon ?receive e3 framer? conditions or upon the content of the ?tx ma byte? register (address = 2ah). ferf and febe values are based upon receive e3 framer conditions if the user selects ?receive e3 framer? conditions, then the transmit e3 framer will set and clear the ferf and febe bit-fields in response to the following conditions. ? ferf bit-field ? if the receive e3 framer (on the same uni chip) is currently experiencing an los, ais, or lof condition, then the transmit e3 framer will set the ?ferf? bit-field (in the ?outbound? e3 frame) to ?1?. conversely, if the receive e3 framer is not experiencing any of these conditions, then the transmit e3 framer will set the ferf bit-field (in the ?outbound? e3 frame) to ?0?. ? febe bit-field ? if the receive e3 framer detects a bip-8 error in the ?incoming? e3 frame, then the transmit e3 framer will set the ?febe? bit-field (in the ?outbound? e3 frame) to ?1?. conversely, if the receive e3 framer does not detect a bip-8 error in the ?incoming? e3 frame, then the transmit e3 framer will set the ?febe? bit-field (in the e3 ?outbound? e3 frame) to ?0?. febe and ferf values are based upon the contents of the ?tx ma byte? register if the user selects the contents of the ?tx ma byte? register, then whatever value has been written into bit 7 (ferf), within the ?tx ma byte? register (address = 2ah); will be the value of the ?ferf? bit-field, in the ?outbound? e3 frame. likewise, whatever value has been written into bit 6 (febe) within the ?tx ma byte? register, will be the value of the ?febe? bit-field, in the ?outbound? e3 frame. writing a ?1? into bit 0 (max) within the ?tx e3 configuration? register configures the transmit e3 framer to set the ?ferf? and ?febe? bit-fields (in the ?outbound? e3 frames) to values based upon ?receive e3 framer? conditions. writing a ?0? into this bit-field configures the transmit e3 framer to set the ?febe? and ?febe? bit-fields (in the ?outbound? e3 frames) to the values written into bit-fields 6 and 7 within the ?tx ma byte? register. 3.3.2.43 tx gc byte register this ?read/write? byte-field allows the user to specify the contents of the gc byte-field in each outbound e3 frame. note: the contents of this register is ignored, if the lapd transmitter is enabled and has been configured to insert the comprising octets of an ?outbound? lapd message frame into the gc byte-field of each outbound e3 frame address = 29h, tx gc byte register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 transmit gc byte r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 75 (e.g., if dlinnr = ?0?). 3.3.2.44 tx ma byte register this ?read/write? byte-fields allows the user to specify the contents of the ma byte-field in each outbound e3 frame . note: the values written into bit-fields 6 (febe) and 7 (ferf) are inserted into ?outbound? e3 frames, only if bit-field 0 (max) within the ?tx e3 configuration? register (address = 28h) is set to ?0?. otherwise, the transmit e3 framer will set the ferf and febe values, within each ?outbound? e3 frame, to values based upon ?receive e3 framer? conditions. 3.3.2.45 tx nr byte register this ?read/write? byte-field allows the user to specify the contents of the nr byte-field in each outbound e3 frame. note: the contents of this register is ignored, if the lapd transmitter is enabled and has been configured to insert the comprising octets of an ?outbound? lapd message frame into the nr byte-field of each outbound e3 frame (e.g., if dlinnr = ?1?). 3.3.2.46 tx ttb-0 register address = 2ah, tx ma byte register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 transmit ma byte ferf febe payload type payload dependent timing marker r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 1 0 0 0 0 address = 2bh, tx nr byte register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 transmit nr byte r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0 address = 2ch, tx ttb-0 register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 transmit trail trace buffer byte-0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 76 this ?read/write? byte-field, along with the ?tx ttb-1? through ?tx ttb-15? registers allows a user to define a ?trail access point identifier? sequence of bytes, that will be transmitted to the ?far-end? terminal. the ?far-end? receiving terminal will use this sequence of bytes to verify that it is connected to the proper ?transmitting ter- minal?. the transmit e3 framer will take the contents of these 16 registers, and insert them into the tr byte of the outbound e3 frame. in the first of a set of 16 e3 frames, the transmit e3 framer will read in the contents of this register, and insert it into the tr byte-field, within the very next outbound e3 frame. this particular byte-field should contain the pattern ?[1, c6, c5, c4, c3, c2, c1, c0]? where c6 through c0 are the results of a crc-7 calculation over the previous 16-byte frame. note: the XR-T7234 e3 uni will not compute this crc-7 value. it is up to the user?s hardware and/or software to compute this value, prior to writing it into this register. 3.3.2.47 tx ttb-1 register this ?read/write? byte-field, along with the ?tx ttb-0? and ?tx ttb-2? through ?tx ttb-15? register allows a user to define a ?trail access point identifier? sequence of bytes, that will be transmitted to the ?far-end? termi- nal. the ?far-end? receiving terminal will use this sequence of bytes to verify that it is connected to the proper ?transmitting terminal?. the transmit e3 framer will take the contents of these 16 registers, and insert them into the tr byte of the outbound e3 frame. in the second of a set of 16 e3 frames, the transmit e3 framer will read in the contents of this register, and insert it into the tr byte-field, within the very next outbound e3 frame. the contents of this register, along with tx ttb-2 through tx ttb-15 are used to transmit 15 ascii characters required for the e.164 numbering format. 3.3.2.48 tx ttb-2 register this ?read/write? byte-field, along with the ?tx ttb-0?, ?tx ttb-1? and ?tx ttb-3? through ?tx ttb-15? regis- ter allows a user to define a ?trail access point identifier? sequence of bytes, that will be transmitted to the ?far- end? terminal. the ?far-end? receiving terminal will use this sequence of bytes to verify that it is connected to the proper ?transmitting terminal?. the transmit e3 framer will take the contents of these 16 registers, and insert them into the tr byte of the outbound e3 frame. in the third of a set of 16 e3 frames, the transmit e3 r/w r/w r/w r/w r/w r/w r/w r/w 1 0 0 0 0 0 0 0 address = 2dh, tx ttb-1 register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 transmit trail trace buffer byte-1 r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0 address = 2eh, tx ttb-2 register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 transmit trail trace buffer byte-2 r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0 address = 2ch, tx ttb-0 register
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 77 framer will read in the contents of this register, and insert it into the tr byte-field, within the very next out- bound e3 frame. the contents of this register, along with tx ttb-1, and tx ttb-3 through tx ttb-15 are used to transmit 15 ascii characters required for the e.164 numbering format. 3.3.2.49 tx ttb-3 register this ?read/write? byte-field, along with the ?tx ttb-0? through ?tx ttb-2? and ?tx ttb-4? through ?tx ttb-15? reg- isters allows a user to define a ?trail access point identifier? sequence of bytes, that will be transmitted to the ?far-end? terminal. the ?far-end? receiving terminal will use this sequence of bytes to verify that it is con- nected to the proper ?transmitting terminal?. the transmit e3 framer will take the contents of these 16 regis- ters, and insert them into the tr byte of the outbound e3 frame. in the fourth of a set of 16 e3 frames, the transmit e3 framer will read in the contents of this register, and insert it into the tr byte-field, within the very next outbound e3 frame. the contents of this register, along with tx ttb-1, tx ttb-2 and tx ttb-4 through tx ttb-15 are used to transmit 15 ascii characters required for the e.164 numbering format. 3.3.2.50 tx ttb-4 register this ?read/write? byte-field, along with the ?tx ttb-0 through tx ttb-3? and ?tx ttb-5? through ?tx ttb-15? reg- isters allows a user to define a ?trail access point identifier? sequence of bytes, that will be transmitted to the ?far-end? terminal. the ?far-end? receiving terminal will use this sequence of bytes to verify that it is con- nected to the proper ?transmitting terminal?. the transmit e3 framer will take the contents of these 16 regis- ters, and insert them into the tr byte of the outbound e3 frame. in the fifth of a set of 16 e3 frames, the transmit e3 framer will read in the contents of this register, and insert it into the tr byte-field, within the very next outbound e3 frame. the contents of this register, along with tx ttb-1 through tx ttb-3 and tx ttb-5 through tx ttb-15 are used to transmit 15 ascii characters required for the e.164 numbering format. address = 2fh, tx ttb-3 register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 transmit trail trace buffer byte-3 r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0 address = 30h, tx ttb-4 register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 transmit trail trace buffer byte-4 r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 78 3.3.2.51 tx ttb-5 register this ?read/write? byte-field, along with the ?tx ttb-0 through tx ttb-4? and ?tx ttb-6? through ?tx ttb-15? registers allows a user to define a ?trail access point identifier? sequence of bytes, that will be transmitted to the ?far-end? terminal. the ?far-end? receiving terminal will use this sequence of bytes to verify that it is connected to the proper ?transmitting terminal?. the transmit e3 framer will take the contents of these 16 registers, and insert them into the tr byte of the outbound e3 frame. in the sixth of a set of 16 e3 frames, the transmit e3 framer will read in the contents of this register, and insert it into the tr byte-field, within the very next outbound e3 frame. the contents of this register, along with tx ttb-1 through tx ttb-4 and tx ttb-6 through tx ttb-15 are used to transmit 15 ascii characters required for the e.164 numbering format. 3.3.2.52 tx ttb-6 register this ?read/write? byte-field, along with the ?tx ttb-0 through tx ttb-5? and ?tx ttb-7? through ?tx ttb-15? reg- isters allows a user to define a ?trail access point identifier? sequence of bytes, that will be transmitted to the ?far- end? terminal. the ?far-end? receiving terminal will use this sequence of bytes to verify that it is connected to the proper ?transmitting terminal?. the transmit e3 framer will take the contents of these 16 registers, and insert them into the tr byte of the outbound e3 frame. in the seventh of a set of 16 e3 frames, the transmit e3 framer will read in the contents of this register, and insert it into the tr byte-field, within the very next outbound e3 frame. the contents of this register, along with tx ttb-1 through tx ttb-5 and tx ttb-7 through tx ttb-15 are used to transmit 15 ascii characters required for the e.164 numbering format. 3.3.2.53 tx ttb-7 register address = 31h, tx ttb-5 register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 transmit trail trace buffer byte-5 r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0 address = 32h, tx ttb-6 register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 transmit trail trace buffer byte -6 r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0 address = 33h, tx ttb-7 register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 transmit trail trace buffer byte-7 r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 79 this ?read/write? byte-field, along with the ?tx ttb-0 through tx ttb-6? and ?tx ttb-8? through ?tx ttb-15? reg- isters allows a user to define a ?trail access point identifier? sequence of bytes, that will be transmitted to the ?far-end? terminal. the ?far-end? receiving terminal will use this sequence of bytes to verify that it is con- nected to the proper ?transmitting terminal?. the transmit e3 framer will take the contents of these 16 regis- ters, and insert them into the tr byte of the outbound e3 frame. in the eighth of a set of 16 e3 frames, the transmit e3 framer will read in the contents of this register, and insert it into the tr byte-field, within the very next outbound e3 frame. the contents of this register, along with tx ttb-1 through tx ttb-6 and tx ttb-8 through tx ttb-15 are used to transmit 15 ascii characters required for the e.164 numbering format. 3.3.2.54 tx ttb-8 register this ?read/write? byte-field, along with the ?tx ttb-0 through tx ttb-7? and ?tx ttb-9? through ?tx ttb-15? reg- isters allows a user to define a ?trail access point identifier? sequence of bytes, that will be transmitted to the ?far-end? terminal. the ?far-end? receiving terminal will use this sequence of bytes to verify that it is con- nected to the proper ?transmitting terminal?. the transmit e3 framer will take the contents of these 16 regis- ters, and insert them into the tr byte of the outbound e3 frame. in the ninth of a set of 16 e3 frames, the transmit e3 framer will read in the contents of this register, and insert it into the tr byte-field, within the very next outbound e3 frame. the contents of this register, along with tx ttb-1 through tx ttb-7 and tx ttb-9 through tx ttb-15 are used to transmit 15 ascii characters required for the e.164 numbering format. 3.3.2.55 tx ttb-9 register this ?read/write? byte-field, along with the ?tx ttb-0 through tx ttb-8? and ?tx ttb-10? through ?tx ttb-15? registers allows a user to define a ?trail access point identifier? sequence of bytes, that will be transmitted to the ?far-end? terminal. the ?far-end? receiving terminal will use this sequence of bytes to verify that it is con- nected to the proper ?transmitting terminal?. the transmit e3 framer will take the contents of these 16 regis- ters, and insert them into the tr byte of the outbound e3 frame. in the tenth of a set of 16 e3 frames, the transmit e3 framer will read in the contents of this register, and insert it into the tr byte-field, within the very next outbound e3 frame. the contents of this register, along with tx ttb-1 through tx ttb-8 and tx ttb-10 through tx ttb-15 are used to transmit 15 ascii characters required for the e.164 numbering format. address = 34h, tx ttb-8 register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 transmit trail trace buffer byte-8 r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0 address = 35h, tx ttb-9 register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 transmit trail trace buffer byte-9 r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 80 3.3.2.56 tx ttb-10 register this ?read/write? byte-field, along with the ?tx ttb-0 through tx ttb-9? and ?tx ttb-11? through ?tx ttb-15? registers allows a user to define a ?trail access point identifier? sequence of bytes, that will be transmitted to the ?far-end? terminal. the ?far-end? receiving terminal will use this sequence of bytes to verify that it is connected to the proper ?transmitting terminal?. the transmit e3 framer will take the contents of these 16 registers, and insert them into the tr byte of the outbound e3 frame. in the eleventh of a set of 16 e3 frames, the transmit e3 framer will read in the contents of this register, and insert it into the tr byte-field, within the very next outbound e3 frame. the contents of this register, along with tx ttb-1 through tx ttb-9 and tx ttb-11 through tx ttb-15 are used to transmit 15 ascii characters required for the e.164 numbering format. 3.3.2.57 tx ttb-11 register this ?read/write? byte-field, along with the ?tx ttb-0 through tx ttb-10? and ?tx ttb-12? through ?tx ttb-15? registers allows a user to define a ?trail access point identifier? sequence of bytes, that will be transmitted to the ?far-end? terminal. the ?far-end? receiving terminal will use this sequence of bytes to verify that it is connected to the proper ?transmitting terminal?. the transmit e3 framer will take the contents of these 16 registers, and insert them into the tr byte of the outbound e3 frame. in the twelfth of a set of 16 e3 frames, the transmit e3 framer will read in the contents of this register, and insert it into the tr byte-field, within the very next outbound e3 frame. the contents of this register, along with tx ttb-1 through tx ttb-10 and tx ttb-12 through tx ttb-15 are used to transmit 15 ascii characters required for the e.164 numbering format. 3.3.2.58 tx ttb-12 register address = 36h, tx ttb-10 register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 transmit trail trace buffer byte-10 r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0 address = 37h, tx ttb-11 register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 transmit trail trace buffer byte-11 r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0 address = 38h, tx ttb-12 register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 transmit trail trace buffer byte-12 r/w r/w r/w r/w r/w r/w r/w r/w
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 81 this ?read/write? byte-field, along with the ?tx ttb-0 through tx ttb-11? and ?tx ttb-13? through ?tx ttb- 15? registers allows a user to define a ?trail access point identifier? sequence of bytes, that will be transmitted to the ?far-end? terminal. the ?far-end? receiving terminal will use this sequence of bytes to verify that it is connected to the proper ?transmitting terminal?. the transmit e3 framer will take the contents of these 16 reg- isters, and insert them into the tr byte of the outbound e3 frame. in the thirteenth of a set of 16 e3 frames, the transmit e3 framer will read in the contents of this register, and insert it into the tr byte-field, within the very next outbound e3 frame. the contents of this register, along with tx ttb-1 through tx ttb-11 and tx ttb-13 through tx ttb-15 are used to transmit 15 ascii characters required for the e.164 numbering format. 3.3.2.59 tx ttb-13 register this ?read/write? byte-field, along with the ?tx ttb-0 through tx ttb-12?, ?tx-ttb-14?, and ?tx ttb-15? reg- isters allows a user to define a ?trail access point identifier? sequence of bytes, that will be transmitted to the ?far-end? terminal. the ?far-end? receiving terminal will use this sequence of bytes to verify that it is con- nected to the proper ?transmitting terminal?. the transmit e3 framer will take the contents of these 16 regis- ters, and insert them into the tr byte of the outbound e3 frame. in the fourteenth of a set of 16 e3 frames, the transmit e3 framer will read in the contents of this register, and insert it into the tr byte-field, within the very next outbound e3 frame. the contents of this register, along with tx ttb-1 through tx ttb-12, tx ttb-14 and tx ttb-15 are used to transmit 15 ascii characters required for the e.164 numbering format. 3.3.2.60 tx ttb-14 register this ?read/write? byte-field, along with the ?tx ttb-0 through tx ttb-13? and ?tx ttb-15? registers allows a user to define a ?trail access point identifier? sequence of bytes, that will be transmitted to the ?far-end? termi- nal. the ?far-end? receiving terminal will use this sequence of bytes to verify that it is connected to the proper ?transmitting terminal?. the transmit e3 framer will take the contents of these 16 registers, and insert them into the tr byte of the outbound e3 frame. in the fifteenth of a set of 16 e3 frames, the transmit e3 framer will read in the contents of this register, and insert it into the tr byte-field, within the very next outbound e3 frame. the contents of this register, along with tx ttb-1 through tx ttb-13 and tx ttb-15 are used to transmit 15 0 0 0 0 0 0 0 0 address = 39h, tx ttb-13 register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 transmit trail trace buffer byte -13 r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0 address = 3ah, tx ttb-14 register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 transmit trail trace buffer byte -14 r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0 address = 38h, tx ttb-12 register
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 82 ascii characters required for the e.164 numbering format. 3.3.2.61 tx ttb-15 register this ?read/write? byte-field, along with the ?tx ttb-0 through tx ttb-14? registers allows a user to define a ?trail access point identifier? sequence of bytes, that will be transmitted to the ?far-end? terminal. the ?far-end? receiv- ing terminal will use this sequence of bytes to verify that it is connected to the proper ?transmitting terminal?. the transmit e3 framer will take the contents of these 16 registers, and insert them into the tr byte of the outbound e3 frame. in the sixteenth of a set of 16 e3 frames, the transmit e3 framer will read in the contents of this register, and insert it into the tr byte-field, within the very next outbound e3 frame. the contents of this register, along with tx ttb-1 through tx ttb-15 are used to transmit 15 ascii characters required for the e.164 numbering format. 3.3.2.62 tx fa1 error mask register this ?read/write? bit-field allows the user to insert errors into the framing alignment octet, fa1 of each ?outbound? e3 frame. the user may wish to do this for equipment testing purposes. prior to transmission, the transmit e3 framer reads in the fa1 byte, and performs an xor operation with it and the contents of this register. the results of this operation are written back into the fa1 octet position, in each outbound e3 frame. consequently, if the user does not wish to inject errors into the fa1 octet of the ?outbound? e3 frames, he/she must insure that the contents of this register are set to all ?0s? (the default value). 3.3.2.63 tx fa2 error mask register address = 3bh, tx ttb-15 register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 transmit trail trace buffer byte-15 r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0 address = 3ch, tx fa1 error mask register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 transmit fa1 byte error mask r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0 address = 3dh, tx fa2 error mask register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 transmit fa2 byte error mask r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 83 this ?read/write? bit-field allows the user to insert errors into the framing alignment octet, fa2 of each ?outbound? e3 frame. the user may wish to do this for equipment testing purposes. prior to transmission, the transmit e3 framer reads in the fa2 byte, and performs an xor operation with it and the contents of this register. the results of this operation are written back into the fa2 octet position, in each outbound e3 frame. consequently, if the user does not wish to inject errors into the fa2 octet of the ?outbound? e3 frames, he/she must insure that the contents of this register are set to all ?0s? (the default value). 3.3.2.64 tx em byte error mask register this ?read/write? bit-field allows the user to insert errors into em (error monitor) octet of each ?outbound? e3 frame. the user may wish to do this for equipment testing purposes. prior to transmission, the transmit e3 framer reads in the em byte, and performs an xor operation with it and the contents of this register. the results of this operation are written back into the em octet position, in each outbound e3 frame. consequently, if the user does not wish to inject errors into the em octet of the ?outbound? e3 frames, he/she must insure that the contents of this register are set to all ?0s? (the default value). 3.3.2.65 tx e3 lapd status/interrupt register bit 3?txdl start this ?read/write? bit-field allows the user to command the lapd transmitter to do the following. ? scan through the pmdl message, within the ?transmit lapd message? buffer, and search for a string of five (5) consecutive ?1s?. the lapd transmitter will then insert (or ?stuff?) a ?0? into the pmdl message data, immediately following any string of 5 consecutive ?1s?. ? read in this ?stuffed? pmdl message from the ?transmit lapd message? buffer, and encapsulate it into a lapd address = 3eh, tx em byte error mask register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 transmit em byte error mask r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0 address = 3fh, tx e3 lapd status/interrupt register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused txdl start txdl busy txlapd interrupt enable txlapd interrupt status ro ro ro ro r/w ro r/w rur 0 0 0 0 0 0 0 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 84 message frame. ? fragment the resulting lapd message frame into octets. ? insert these octets into either the gc byte-field or the nr byte-field (depending upon the user?s selection) in each ?outbound? e3 frame. a ?0? to ?1? transition, in this bit-field commands the lapd transmitter to initiate the ?above-mentioned? procedure. ? once the user has commanded the lapd transmitter to start transmission, the lapd transmitter will repeat the ?above-mentioned? process once each second; and will insert flag sequence octets into the ?outbound? lapd channel, during the idle periods between transmissions. bit 2? txdl busy this ?read-only? bit-field allows the user to poll or monitor the status of the lapd transmitter to see if it has com- pleted its transmission of the lapd message frame. the lapd transmitter will set this bit-field to ?1?, while it is in the process of transmitting the lapd message frame. however, the lapd transmitter will clear this bit-field to ?0? once it has completed its transmission of the lapd message frame. bit 1?txlapd interrupt enable this ?read/write? bit-field allows the user to enable or disable the ?lapd message frame transmission complete? interrupt. writing a ?0? to this bit-field disables this interrupt. writing a ?1? to this bit-field enables this interrupt. bit 0?txlapd interrupt status this ?reset-upon-read? bit-field allows the user to determine if the ?lapd message frame transmission complete? interrupt has occurred since the last read of this register. if this bit-field contains a ?1? then the ?lapd message frame transmission complete? interrupt has occurred since the last read of this register. conversely, if this bit-field contains a ?0? then it has not. 3.3.2.66 pmon lcv event count register?msb this ?reset-upon-read? register, along with the ?pmon lcv event count register?lsb? (address = 41h) contains a 16-bit representation of the number of ?line code violations? that have been detected by the receive e3 framer, since the last read of these registers. this register contains the msb (or upper-byte) value of this 16 bit expression. address = 40h, pmon lcv event count register?msb bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 lcv count?high byte rur rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 85 3.3.2.67 pmon lcv event count register?lsb this ?reset-upon-read? register, along with the ?pmon lcv event count register - msb (address 40h), con- tain a 16 bit representation of the number of ?line code violations? that have been detected by the receive e3 framer, since the last read of these registers. this register contains the lsb (or lower byte) value of this 16 bit expression. 3.3.2.68 pmon framing byte error event count register?msb this ?reset-upon-read? register, along with the ?pmon framing byte error event count register?lsb? (address = 43h) contains a 16 bit representation of the number of ?framing byte errors? (e.g., in the fa1 and fa2 octets) that have been detected by the receive e3 framer, since the last read of these registers. this register contains the msb (or upper byte) value of this 16 bit expression. note: if the user is interfacing the local m p / m c to the microprocessor interface of the uni chip over an 8 bit data bus; then immediately after reading this register, the local m p / m c can also read the contents of the ?pmon framing bit error event count register?lsb? by reading the ?pmon holding register? (address = 56h). 3.3.2.69 pmon framing byte error event count register?lsb this ?reset-upon-read? register, along with the ?pmon framing byte error event count register?msb? (address = 42h) contains a 16 bit representation of the number of ?framing bytes errors? (e.g., in the fa1 and fa2 octets) that have been detected by the receive e3 framer, since the last read of these registers. this register contains the lsb (or lower byte) value of this 16 bit expression. note: if the user is interfacing the local m p / m c to the microprocessor interface of the uni chip over an 8 bit data bus; then immediately after reading this register, the local m p / m c can also read the contents of the ?pmon framing bit error event count register?msb? by reading the ?pmon holding register? (address = 56h). address = 41h, pmon lcv event count register?lsb bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 lcv count?low byte rur rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0 address = 42h, pmon framing byte error event count register - msb bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 framing byte error count?high byte rur rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0 address = 43h, pmon framing byte error event count register?lsb bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 framing byte error count?low byte rur rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 86 3.3.2.70 pmon received febe event count register?msb this ?reset-upon-read? register, along with the pmon received febe event count register?lsb? (address = 45h) contains a 16 bit representation of the number of number of e3 frames (received by the receive e3 framer) that contain a ?1? in the febe bit-field; since the last read of these registers. this register contains the msb (or upper byte) value of this 16 bit expression. 3.3.2.71 pmon received febe event count register?lsb this ?reset-upon-read? register, along with the pmon received febe event count register - msb? (address = 44h) contains a 16 bit representation of the number of number of e3 frames (received by the receive e3 framer) that contain a ?1? in the febe bit-field; since the last read of these registers. this register contains the lsb (or lower byte) value of this 16 bit expression. 3.3.2.72 pmon framer bip-8 error event count register?msb this ?reset-upon-read? register, along with the ?pmon framer bip-8 error event count register?lsb? (address = 47h) contains a 16-bit representation of the number of e3 frames, containing em byte errors, that have been detected by the receive e3 framer, since the last read of these registers. this registers contains the msb (or upper byte) value of this 16-bit expression. address = 44h, pmon received febe event count register?msb bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 received febe event count?high byte rur rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0 address = 45h, pmon received febe event count register?lsb bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 received febe event count?low byte rur rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0 address = 46h, pmon framer bip-8 error event count register?msb bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 framer bip-8 error count?high byte rur rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 87 3.3.2.73 pmon framer bip-8 error event count register?lsb this ?reset-upon-read? register, along with the ?pmon framer bip-8 error event count register?msb? (address = 46h) contains a 16-bit representation of the number of e3 frames, containing em byte errors, that have been detected by the receive e3 framer, since the last read of these registers. this registers contains the lsb (or lower byte) value of this 16-bit expression. 3.3.2.74 pmon received single-bit hec error count?msb this ?reset-upon-read? register, along with the ?pmon received single hec error count?lsb? register (address = 49h) contains a 16 bit representation of the number of ?single bit hec errors? that have been detected by the receive cell processor, since the last read of these registers. this register contains the msb (or upper byte) value of this 16-bit expression. 3.3.2.75 pmon received single-bit hec error count?lsb this ?reset-upon-read? register, along with the ?pmon received single hec error count?msb? register (address = 48h) contains a 16 bit representation of the number of ?single bit hec errors? that have been detected by the receive cell processor, since the last read of these registers. this register contains the lsb (or lower byte) value of this 16-bit expression. address = 47h, pmon framer bip-8 error event count register?lsb bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 framer bip-8 error count?low byte rur rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0 address = 48h, pmon received single-bit hec error count?msb bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 s-hec error count?high byte rur rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0 address = 49h, pmon received single-bit hec error count?lsb bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 s-hec error count?low byte rur rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 88 3.3.2.76 pmon received multiple-bit hec error?msb this ?reset-upon-read? register, along with the ?pmon received multiple hec error count?lsb? register (address = 4bh) contains a 16 bit representation of the number of ?multiple-bit hec errors? that have been detected by the receive cell processor, since the last read of these registers. this register contains the msb (orupper byte) value of this 16-bit expression. 3.3.2.77 pmon received multiple-bit hec error?lsb this ?reset-upon-read? register, along with the ?pmon received multiple hec error count - msb? register (address = 4ah) contains a 16 bit representation of the number of ?multiple-bit hec errors? that have been detected by the receive cell processor, since the last read of these registers. this register contains the lsb (orlower byte) value of this 16-bit expression. 3.3.2.78 pmon received idle cell count?msb this ?reset-upon-read? register, along with the ?pmon received idle cell count?lsb? register (address = 4dh) contains a 16 bit representation of the number of ?idle cells? that have been detected by the receive cell address = 4ah, pmon received multiple-bit hec error?msb bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 m-hec error count?high byte rur rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0 address = 4bh, pmon received multiple-bit hec error?lsb bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 m-hec error count?low byte rur rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0 address = 4ch, pmon received idle cell count?msb bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx idle cell count?high byte rur rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 89 processor , since the last read of these register. this register contains the msb (or upper byte) value of this 16-bit expression. 3.3.2.79 pmon received idle cell count?lsb this ?reset-upon-read? register, along with the ?pmon received idle cell count?msb? register (address = 4ch) contains a 16 bit representation of the number of ?idle cells? that have been detected by the receive cell processor , since the last read of these register. this register contains the lsb (or lower byte) value of this 16-bit expression. 3.3.2.80 pmon received valid cell count?msb this ?reset-upon-read? register, along with the ?pmon received valid cell count?lsb? register (address = 4fh) contains a 16 bit representation of the number of ?user (or assigned) cells? that have been detected by the receive cell processor, since the last read of these register. this register contains the msb (or upper byte) value of this 16-bit expression. 3.3.2.81 pmon received valid cell count?lsb address = 4dh, pmon received idle cell count?lsb bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx idle cell count?low byte rur rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0 address = 4eh, pmon received valid cell count?msb bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx valid cell count?high byte rur rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0 address = 4fh, pmon received valid cell count?lsb bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx valid cell count?low byte rur rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 90 this ?reset-upon-read? register, along with the ?pmon received valid cell count?msb? register (address = 4eh) con- tains a 16 bit representation of the number of ?user (or assigned) cells? that have been detected by the receive cell processor, since the last read of these register. this register contains the lsb (or lower byte) value of this 16-bit expression. 3.3.2.82 pmon discarded cell count?msb this ?reset-upon-read? register, along with the ?pmon discarded cell count- lsb? register (address = 51h) contain s a 16 bit representation of the number of cells that have been discarded by the receive cell processor, since the last read of these registers. this register contains the msb (or upper byte) value of this 16 bit expres- sion. please note that this expression includes idle cells, cells with hec byte errors, and cells filtered or removed by the user cell filter. 3.3.2.83 pmon discarded cell count?lsb this ?reset-upon-read? register, along with the ?pmon discarded cell count- msb? register (address = 50h) con- tains a 16 bit representation of the number of cells that have been discarded by the receive cell processor, since the last read of these registers. this register contains the lsb (or lower byte) value of this 16 bit expres- sion. please note that this expression includes idle cells, cells with hec byte errors, and cells filtered or removed by the user cell filter. 3.3.2.84 pmon transmitted idle cell count?msb this ?reset-upon-read? register, along with the ?pmon transmitted idle cell count?lsb? register (address = 53h) address = 50h, pmon discarded cell count?msb bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 cell drop count?high byte rur rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0 address = 51h, pmon discarded cell count?lsb bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 cell drop count?low byte rur rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0 address = 52h, pmon transmitted idle cell count?msb bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 tx idle cell count?high byte rur rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 91 contains a 16-bit representation of the number of ?idle cells? that have been generated and transmitted by the transmit cell processor, since the last read of these registers. this register contains the msb (or upper byte) value of this 16 bit expression. 3.3.2.85 pmon transmitted idle cell count?lsb this ?register-upon-read? register, along with the ?pmon transmitted idle cell count?msb? register (address = 52h) contains a 16-bit representation of the number of ?idle cells? that have been generated and transmitted by the transmit cell processor, since the last read of these registers. this register contains the lsb (or lower byte) value of this 16 bit expression. 3.3.2.86 pmon transmitted valid cell count?msb this ?reset-upon-read? register, along with the ?pmon transmitted valid cell count?lsb? register (address = 55h) contains a 16-bit representation of the number of ?user (or assigned) cells? that have been generated and transmitted by the transmit cell processor, since the last read of these registers. this register contains the msb (or upper byte) value of this 16 bit expression. 3.3.2.87 pmon transmitted valid cell count?lsb this ?reset-upon-read? register, along with the ?pmon transmitted valid cell count?msb? register (address = 54h) contains a 16-bit representation of the number of ?user (or assigned) cells? that have been generated address = 53h, pmon transmitted idle cell count?lsb bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 tx idle cell count?low byte rur rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0 address = 54h, pmon transmitted valid cell count?msb bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 tx valid cell count?high byte rur rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0 address = 55h, pmon transmitted valid cell count?lsb bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 tx valid cell count?low byte rur rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 92 and transmitted by the transmit cell processor, since the last read of these registers. this register contains the lsb (or lower byte) value of this 16 bit expression. 3.3.2.88 pmon holding register this register is of use if the user is operating the uni in the 8-bit m p access mode. when the m p reads out a partic- ular pmon counter, one second accumulator, or test cell error accumulator (16 bit registers), it will read out one of two 8-bit registers. the contents of the other 8-bit register will be stored in this register. for more information on this operation, please see section 3.5. 3.3.2.89 one second error status register bit 1?errored second this ?read-only? bit-field indicates whether or not there were any errors during the last one second interval. if this bit-field is ?0? then there were no errors during the last one second interval. if this bit-field is ?1?, then there was at least one error during the last one second interval. bit 0?severe errored second this ?read-only? bit-field indicates whether or not the bit-error rate, of the last one second interval, exhibited a ber (bit error rate) exceeding 10-3. a ?0? in this bit-field indicates that the ber for the last one-second interval was less than 10-3. conversely, a ?1? in this bit-field indicates that the ber for the last one-second interval exceeds 10-3. 3.3.2.90 lcv-one second accumulator register?msb address = 56h, pmon holding register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 pmon hold value ro ro ro ro ro ro ro ro 0 0 0 0 0 0 0 0 address = 57h, one second error status register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused errored sec severe errored sec ro ro ro ro ro ro ro ro 0 0 0 0 0 0 0 0 address = 58h, lcv-one second accumulator register?msb bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 93 this register, along with ?lcv-one second accumulator register?lsb? (address = 59h) presents a 16-bit repre- sentation of the number of line code violations that have been detected by the receive e3 framer, during the last one second interval. this register presents the msb (upper-byte) value of this expression. 3.3.2.91 lcv-one second accumulator register?lsb this register, along with ?lcv-one second accumulator register?lsb? (address = 58h) presents a 16-bit repre- sentation of the number of line code violations that have been detected by the receive e3 framer, during the last one second interval. this register presents the lsb (lower-byte) value of this expression. 3.3.2.92 framer bip-8 error?one second accumulator register?msb this register, along with ?frame bip-8 errors?one second accumulator register?lsb? (address = 5bh) presents a 16-bit representation of the number of e3 frames, containing em byte errors, that have been detected by the receive e3 framer, during the last one second interval. this register presents the msb (upper-byte) value of this expression. 3.3.2.93 framer bip-8 errors?one second accumulator register?lsb lcv 1 sec?high byte ro ro ro ro ro ro ro ro 0 0 0 0 0 0 0 0 address = 59h, lcv-one second accumulator register?lsb bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 lcv 1 sec?low byte ro ro ro ro ro ro ro ro 0 0 0 0 0 0 0 0 address = 5ah, framer bip-8 errors?one second accumulator register?msb bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 framer bip-8 error 1 sec?high byte ro ro ro ro ro ro ro ro 0 0 0 0 0 0 0 0 address = 5bh, framer bip-8 errors?one second accumulator register?lsb bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 address = 58h, lcv-one second accumulator register?msb
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 94 this register, along with ?frame bip-8 errors?one second accumulator register - msb? (address = 5ah) pre- sents a 16-bit representation of the number of e3 frames, containing em byte errors, that have been detected by the receive e3 framer, during the last one second interval. this register presents the lsb (lower-byte) value of this expression. 3.3.2.94 hec errors?one second accumulator register?msb this register, along with ?hec errors?one second accumulator register?lsb? (address = 5dh) presents a 16-bit representation of the number cells with hec errors that have been detected by the receive cell proces- sor, during the last one second interval. this register presents the msb (upper-byte) value of this expression. 3.3.2.95 hec errors?one second accumulator register?lsb this register, along with ?hec errors?one second accumulator register?msb? (address = 5ch) presents a 16-bit representation of the number cells with hec errors that have been detected by the receive cell proces- sor, during the last one second interval. this register presents the lsb (lower-byte) value of this expression. 3.3.2.96?rx cp configuration register framer bip-8 error 1 sec?low byte ro ro ro ro ro ro ro ro 0 0 0 0 0 0 0 0 address = 5ch, hec errors?one second accumulator register?msb bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 hec errors 1 sec?high byte ro ro ro ro ro ro ro ro 0 0 0 0 0 0 0 0 address = 5dh, hec errors - one second accumulator register - lsb bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 hec errors 1 sec?low byte ro ro ro ro ro ro ro ro 0 0 0 0 0 0 0 0 address = 5eh, rx cp configuration register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 lcd rdpchkpat rdpchk pat enable c discard oam check bit de- scramblei enable rx coset enable hec error ignore\ enable ro r/w r/w r/w r/w r/w r/w r/w address = 5bh, framer bip-8 errors?one second accumulator register?lsb
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 95 bit 7?lcd (loss of cell delineation) this ?read only? bit-field indicates whether or not the receive cell processor is currently experiencing a ?loss of cell delineation?. if this bit-field is ?0?, then the receive cell processor is currently not experiencing a ?loss of cell delineation? and is properly delineating the atm cell data that it receives from the receive e3 framer. if this bit-field is ?1?, then the receive cell processor is currently experiencing a ?loss of cell delineation? and is not properly delineating the atm cell data that it receives from the receive e3 framer. for more information on cell delineation by the receive cell processor, please see section 7.2.2.1. bit 6?rdpchk (receive ?data path integrity check?)pattern the ?read/write? bit-field allows the user to select which of two possible ?data path integrity check? patterns that the receive cell processor will insert into the fifth octet of each cell that is written into the rxfifo. the ?data path integrity check? pattern options are: ? an alternating pattern of ?55h?/?aah?. ? a constant pattern of ?55h?. writing a ?0? to this bit-field selects the alternating pattern. writing a ?1? to this bit-field selects the constant pattern. note: this bit-field is ignored if bit 5 (of this register) is set to ?0?. bit 5?rdpchk (receive ?data path integrity check?) pattern enable this ?read/write? bit-field allows the user to enable or disable the insertion of the ?data path integrity check? pattern into the 5th octet of each cell that is written into the rxfifo. writing a ?0? into this bit-field disables the insertion of the ?data path integrity check? pattern into the 5th octet of the cell (e.g., the cell, with its hec byte, will be written into the rxfifo). conversely, writing a ?1? into this bit-field enables this features (e.g., the hec byte of each cell will be overwritten by the ?data path integrity check? pattern). the ?data path integrity check? pattern, that is written into the cell depends upon the setting of bit 6 (rdpchk) within this register. for more information on this topic, please see section 7.2.2.6. bit 4?ic (idle cell) discard this ?read/write? bit-field allows the user to configure the receive cell processor to either discard or retain idle cells. if the user configures the receive cell processor to discard idle cells, then the idle cells will be discarded and will not be written into the rx fifo. if the user configures the receive cell processor to retain idle cells, then all idle cells will be retained and can be (depending upon the user cell filter settings) written to the rx fifo. writing a ?0? to this bit-field configures the receive cell processor to retain idle cells. writing a ?1? to this bit-field configures the receive cell processor to discard idle cells. for more information on the handling of idle cells by the receive cell processor, please see section 7.2.2.3.1. bit 3?oam check bit this ?read/write? bit-field allows the user to configure the receive cell processor to ?check? the next oam cell, that it receives. specifically, this means that the receive cell processor, upon identifying an incoming oam cell, will copy the header and payload bytes of this cell to the ?received oam cell? buffer (in on-chip ram). if the user does not 1 0 0 1 1 1 1 0 address = 5eh, rx cp configuration register
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 96 configure the receive cell processor to perform an ?oam cell check?, the oam cell will simply be treated like any other user cell, as it is processed through the user cell filter, where it can be discarded or written to the rx fifo. writing a ?0? to this bit-field disables the ?oam cell check? feature. writing a ?1? to this bit-field enables this feature. bit 2?de-scramble enable this ?read/write? bit-field allows the user to enable or disable the cell descrambler, within the receive cell processor. when the cell descrambler is enabled, the receive cell processor will ?presume? that the payload portion of each incoming cell has been scrambled by the ?far-end? transmit cell processor. therefore, the receive cell processor will modify the contents of the cell payload accordingly. if the cell descrambler is disabled, then the receive cell processor will perform no modifications to the payload byte, of the incoming cells. writing a ?0? to this bit-field disables the cell de-scrambler. writing a ?1? to this bit-field enables the cell descrambler. for more information on cell scrambling and cell descrambling, please see sections 6.2.2.2 and 7.2.2.5. bit 1?rx coset enable this ?read/write? bit-field allows the user to configure the receive cell processor to account for (or to not account for) the ?far-end? transmit cell processor?s modulo-2 addition of the coset polynomial: x6 + x4 + x2 + 1 to the ?orig- inal? hec byte, during hec byte calculation and insertion. if the user configures the receive cell processor to account for the coset polynomial, then the receive cell pro- cessor will go through the following procedure during hec byte verification: ? recompute the ?original? hec (crc-8) byte, based upon the values of bytes 1 through 4 in the received cell. ? modulo-2 add the coset polynomial to the crc-8 byte, thereby creating the ?hec byte?. ? compare the locally computed hec byte with the fifth octet of the incoming cell. if the user configures the receive cell processor to not account for the coset polynomial, then the receive cell processor will go through the following procedure during hec byte verification: ? recompute the hec byte, based upon the values of bytes 1 through 4 in the received cell. ? compare the locally computed hec byte with the fifth octet of the incoming cell. writing a ?0? to this bit-field configures the receive cell processor to not account for the coset polynomial. writ- ing a ?1? to this bit-field configures the receive cell processor to account for the coset polynomial. bit 0?hec error ignore this ?read/write? bit-field allows the user to configure the receive cell processor to either discard or retain cells with hec byte errors. if the user configures the receive cell processor to discard these errored cells (the default condition), then all incoming cells containing single-bit (when the receive cell processor is operating in the ?detection mode?) or multi-bit errors in their header bytes, will be discarded and will not be written to the rx fifo. (note: if the receive cell processor is operating in the ?correction mode?, then those cells that contain single-bit errors will be corrected, via the hec byte verification algorithm, and will not be discarded). if the user configures the receive cell processor to retain these errored cells, then all incoming cells containing single-bit or multi-bit errors in their headers, will not be discarded, and may (depending upon the idle or user cell filter settings) be written to the rx fifo. writing a ?0? to this bit-field disables this feature (e.g., the receive cell processor will discard errored cells). writing a ?1? to this bit-field enable this features (e.g., the receive cell processor will retain errored cells.) note: for more information on this feature, please see section 7.2.2.2.
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 97 3.3.2.97?rx cp additional configuration register bit 5?user cell filter discard this ?read/write? bit-field allows the user to specify which valid cells (e.g., non-idle cells) are to be discarded by the user cell filter. writing a ?0? to this bit-field causes the user cell filter to discard all user cells not matching the header byte patterns, as defined in the ?rx cp user cell filter pattern header byte? registers and the ?rx cp user cell filter mask header byte? registers. writing a ?1? to this bit-field causes the user cell filter to discard all users cells matching the header byte patterns , as defined in the ?rx cp user filter cell pattern header byte? registers and the ?rx cp user cell filter mask header byte? registers. for more information on the user cell filter, please see section 7.2.2.3.2. bit 4?user cell filter enable this ?read/write? bit-field allows the user to enable or disable the user (or assigned) cell filter. if the user cell filter is disabled then all non-idle cells will be written the rx fifo, within the receive utopia interface block. however, if the user cell filter is enabled, then only those user cells, specified by the following parameters; will be written into the rx fifo. ? the contents of bit-field number 5, within this register (user cell filter discard). ? the contents of the four ?rx cp user cell filter pattern header byte? registers (address = 6ah through 6dh), and ? the contents of the four ?rx cp user cell filter mask header byte? registers (address = 6eh through 71h) writing a ?0? to this bit-field disables the user cell filter. writing a ?1? enables the user cell filter. for more information on the user cell filter, please see section 7.2.2.3.2. bits 3 and 2?correction threshold[1, 0] these two ?read/write? bit-fields allow the user to define the correction threshold, ?m?, as specified below. for more information on correction thresholds, please see section 7.2.2.2. ? correction threshold[1, 0] = 0, 0, then m = 0 the receive cell processor, while performing hec byte verification, will always operate in the ?correction? mode. ? correction threshold[1, 0] = 0, 1, then m = 1 address = 5fh, rx cp additional configuration register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused user cell filter discard user cell filter enable corr thresh[1] corr thresh[0] corr enable unused ro ro r/w r/w r/w r/w r/w ro 0 0 0 0 1 1 1 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 98 the receive cell processor, while performing hec byte verification, must detect a single ?error-free? cell before it will transition from the ?detection? mode to the ?correction? mode. ? correction threshold[1, 0] = 1, 0, then m = 3 the receive cell processor, while performing hec byte verification, must detect 3 consecutive ?error-free? cells before it will transition from the ?detection? mode to the ?correction? mode. ? correction threshold[1, 0] = 1, 1, then m = 7 the receive cell processor, while performing hec byte verification, must detect 7 consecutive ?error-free? cells before it will transition from the ?detection? mode to the ?correction? mode. bit 1?correction enable this ?read/write? bit-field allows the user to enable or disable the ?correction? mode, within the ?hec byte verifica- tion? algorithm. specifically, if the user disables the ?correction? mode, then the receive cell processor, while per- forming hec byte verification, will only operate in the ?detection? mode (e.g., cells with single-bit errors are not corrected, and are subject to discard). writing a ?0? to this bit-field disables the ?correction? mode. writing a ?1? to this bit-field enables the ?correction? mode. for more information on the correction mode, within the hec byte verification algorithm, please see section 7.2.2.2. 3.3.2.98?rx cp interrupt enable register bit 2?oam (cell received) interrupt enable this ?read/write? bit-field allows the user to enable or disable the ?received oam cell? interrupt. writing a ?0? to this bit-field disables the ?received oam cell? interrupt. writing a ?1? enables this interrupt. bit 1? ?change in lcd (loss of cell delineation) condition? interrupt enable this ?read/write? bit-field allows the user to enable or disable the ?change in loss of cell delineation condi- tion? interrupt. writing a ?0? to this bit-field disables the ?change in loss of cell delineation condition? interrupt. writing a ?1? enables this interrupt. bit 0? ?detection of hec byte error? interrupt enable this ?read/write? bit-field allows the user to enable or disable the ?detection of hec byte error? interrupt. writing a ?0? to this bit-field disables the ?detection of hec error? interrupt. writing a ?1? enables this interrupt. address = 60h, rx cp interrupt enable register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused oam interrupt enable lcd interrupt enable hec error interrupt enable ro ro ro ro ro r/w r/w r/w 0 0 0 0 0 0 0 0
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 99 3.3.2.99?rx cp interrupt status register bit 2?oam (cell received) interrupt status this ?reset-upon-read? bit-field indicates whether or not the ?received oam cell? interrupt has occurred since the last read of this register. this interrupt will occur if the ?receive oam cell? buffer has a new oam cell that needs to be read and processed by the local m p . if this bit-field is ?0? then the ?received oam cell? interrupt has not occurred since the last read of this register. if this bit-field is ?1?, then the ?oam cell received? interrupt has occurred since the last read of this register. for more information on this interrupt, please see section 7.2.2.4. bit 1??change in lcd (loss of cell delineation) condition? interrupt status this ?reset-upon-read? bit-field indicates whether or not the ?change in loss of cell delineation condition? interrupt has occurred since the last read of this register. the receive cell processor will generate this interrupt if either of the following two events occur. 1. if the receive cell processor (while operating in the ?sync? state) detects too many consecutive cells with hec byte errors, and declares itself to be in the ?hunt? state. at this point, the receive cell processor will not be delineating cells; and will cease to write anymore cells into the rxfifo. 2. once the receive cell processor has transitioned from the ?presync? state and into the ?sync? state, within the ?cell delineation? algorithm (see figure 71). if this bit-field is ?0?, then the ?change in loss of cell delineation condition? interrupt has not occurred since the last read of this register. if this bit-field is ?1?, then the ?change in loss of cell delineation condition? interrupt has occurred since the last read of this register. for more information on this interrupt and cell delineation, please see section 7.2.2.1.2. bit 0? ?detection of hec byte error? interrupt status this ?reset-upon-read? bit-field indicates whether or not the ?detection of hec byte error? interrupt has occurred since the last read of this register. this interrupt will occur if the receive cell processor detects a single-bit or multi-bit hec byte error in an incoming cell that it receives from the receive e3 framer. if this bit-field is ?0?, then the ?detection of hec byte error? interrupt has not occurred since the last read of this register. if this bit-field is ?1?, then the ?detection of hec byte error? interrupt has occurred since the last read of this register. address = 61h, rx cp interrupt status register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused oam interrupt status lcd interrupt status hec error interrupt status ro ro ro ro ro rur rur rur 0 0 0 0 0 0 0 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 100 3.3.2.100 - rx cp idle cell pattern header?byte 1 this ?read/write? register along with the ?rx cp idle cell pattern header?bytes, 2 through 4? registers are used to specify, to the receive cell processor, the header byte patterns for idle cells. the receive cell processor will use this information to identify the idle cells from the stream of cells that it receives from the receive e3 framer. the purpose of this particular register (along with the ?rx cp idle cell mask header?byte 1? register) is to allow the user to define the pattern for header byte 1 of the idle cells. for more information on idle cell handling, please see section 7.2.2.3.1. 3.3.2.101?rx cp idle cell pattern header?byte 2 this ?read/write? register along with the ?rx cp idle cell pattern header -bytes, 1, 3 and 4? registers are used to specify, to the receive cell processor, the header byte patterns for idle cells. the receive cell processor will use this information to identify the idle cells from the stream of cells that it receives from the receive e3 framer. the purpose of this particular register (along with the ?rx cp idle cell mask header?byte 2? register) is to allow the user to define the pattern for header byte 2 of the idle cells. for more information on idle cell handling, please see section 7.2.2.3.1. 3.3.2.102?rx cp idle cell pattern?byte 3 address = 62h, rx cp idle cell pattern header?byte 1 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx idle cell pattern?byte 1 r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0 address = 63h, rx cp idle cell pattern heade?byte 2 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx idle cell pattern?byte 2 r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0 address = 64h, rx cp idle cell pattern header?byte 3 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx idle cell pattern?byte 3 r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 101 this ?read/write? register along with the ?rx cp idle cell pattern header -bytes, 1, 2, and 4? registers are used to specify, to the receive cell processor, the header byte patterns for idle cells. the receive cell pro- cessor will use this information to identify the idle cells from the stream of cells that it receives from the receive e3 framer. the purpose of this particular register (along with the ?rx cp idle cell mask header - byte 3? register) is to allow the user to define the pattern for header byte 3 of the idle cells. for more information on idle cell handling, please see section 7.2.2.3.1. 3.3.2.103?rx cp idle cell pattern header?byte 4 this ?read/write? register along with the ?rx cp idle cell pattern header -bytes, 1 through 3? registers are used to specify, to the receive cell processor, the header byte patterns for idle cells. the receive cell pro- cessor will use this information to identify the idle cells from the stream of cells that it receives from the receive e3 framer. the purpose of this particular register (along with the ?rx cp idle cell mask header?byte 4? register) is to allow the user to define the pattern for header byte 4 of the idle cells. for more information on idle cell handling, please see section 7.2.2.3.1. 3.3.2.104?rx cp idle cell mask header?byte 1 this ?read/write? register allows the user to specify which bit(s), in byte 1 of the incoming idle cell (in the receive cell processor) are to be checked against the corresponding bit(s) in the ?rx cp idle cell pattern header?byte 1? register (address = 62h) by the idle cell filter, when the receive cell processor is trying to determine if an incoming cell is an idle cell or not. writing a ?1? into a particular bit-field in this register, forces the receive cell processor to check and compare the corresponding bit in within octet 1 of the incoming cell with the corresponding bit-field in the ?rx cp idle cell pattern header?byte 1? register. writing a ?0? into a particular bit-field, causes the receive cell processor to treat the corresponding bit within octet 1 in the incoming cell as a ?don?t care? (e.g., to forgo the comparison between the corresponding bit in byte 1 of the incoming cell with the corresponding bit-field in the ?rx cp idle cell pattern header?byte 1? reg- ister.) for more information on idle cell handling, please see section 7.2.2.3.1. address = 65h, rx cp idle cell pattern header - byte 4 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx idle cell pattern?byte 4 r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 1 address = 66h, rx cp idle cell mask header?byte 1 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx idle cell mask header?byte 1 r/w r/w r/w r/w r/w r/w r/w r/w 1 1 1 1 1 1 1 1
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 102 3.3.2.105?rx cp idle cell mask header?byte 2 this ?read/write? register allows the user to specify which bit(s), in byte 2 of the incoming cell (in the receive cell processor) are to be checked against the corresponding bit(s) in the ?rx cp idle cell pattern header - byte 2? register (address = 63h) by the idle cell filter, when the receive cell processor is trying to determine if an incoming cell is an idle cell or not. writing a ?1? into a particular bit-field in this register, forces the receive cell processor to check and compare the corresponding bit within octet 2 of the incoming cell with the corresponding bit in the ?rx cp idle cell pattern header?byte 2? register. writing a ?0? into a particular bit-field, causes the receive cell processor to treat the corresponding bit within octet 2 in the incoming cell as a ?don?t care? (e.g., to forgo the comparison between the corresponding bit in byte 2 of the incoming cell with the corresponding bit in the ?rx cp idle cell pattern header?byte 2? register.) for more information on idle cell handling, please see section 7.2.2.3.1. 3.3.2.106?rx cp idle cell mask header?byte 3 this ?read/write? register allows the user to specify which bit(s), in byte 3 of the incoming idle cell (in the receive cell processor) are to be checked against the corresponding bit(s) in the ?rx cp idle cell pattern header?byte 3? register (address = 64h) by the idle cell filter, when the receive cell processor is trying to determine if an incoming cell is an idle cell or not. writing a ?1? into a particular bit-field in this register, forces the receive cell processor to check and compare the corresponding bit within octet 3 of the incoming cell with the corresponding bit in the ?rx cp idle cell pattern header?byte 3? register. writing a ?0? into a particular bit-field, causes the receive cell processor to treat the corresponding bit within octet 3 in the incoming cell as a ?don?t care? (e.g., to forgo the comparison between the corresponding bit within octet 3 of the incoming cell with the corresponding bit in the ?rx cp idle cell pattern header?byte 3? register.) for more information on idle cell handling, please see section 7.2.2.3.1. address = 67h, rx cp idle cell mask header?byte 2 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx idle cell mask header?byte 2 r/w r/w r/w r/w r/w r/w r/w r/w 1 1 1 1 1 1 1 1 address = 68h, rx cp idle cell mask header?byte 3 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx idle cell mask header?byte 3 r/w r/w r/w r/w r/w r/w r/w r/w 1 1 1 1 1 1 1 1
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 103 3.3.2.107?rx cp idle cell mask header?byte 4 this ?read/write? register allows the user to specify which bit(s), in byte 4 of the incoming idle cell (in the receive cell processor) are to be checked against the corresponding bit(s) in the ?rx cp idle cell pattern header?byte 4? register (address = 65h) by the idle cell filter, when the receive cell processor is trying to determine if an incoming cell is an idle cell or not. writing a ?1? into a particular bit-field in this register, forces the receive cell processor to check and compare the corresponding bit within octet 4 of the incoming cell with the corresponding bit in the ?rx cp idle cell pat- tern header?byte 4? register. writing a ?0? into a particular bit-field, causes the receive cell processor to treat the corresponding bit within octet 1 in the incoming cell as a ?don?t care? (e.g., to forgo the comparison between the corresponding bit within octet 4 of the incoming cell with the corresponding bit-field in the ?rx cp idle cell pattern header?byte 4? reg- ister.) for more information on idle cell handling, please see section 7.2.2.3.1. 3.3.2.108?rx cp user cell filter pattern header?byte 1 the user (or assigned) cell filtering criteria is defined based upon the contents of 8 read/write registers. these registers are the four ?rx cp user cell filter pattern header byte? registers, and the four ?rx cp user cell fil- ter mask header byte? registers. this ?read/write? register, along with the ?rx cp user cell filter mask header?byte 1? register (address = 6eh) allows the user to define the user (or assigned) cell filtering criteria for octet 1 of the incoming user cell. the user will write in the header byte pattern for octet 1, that he/she wishes to use as part of the user cell filtering criteria, into this register. the user will also write in a value to the ?rx cp user cell filter mask header - byte 1? register, that indicates which bits within the first octet of the incoming cell are to be compared with the contents of this register. address = 69h, rx cp idle cell mask header?byte 4 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx idle cell mask header?byte 1 r/w r/w r/w r/w r/w r/w r/w r/w 1 1 1 1 1 1 1 1 address = 6ah, rx cp user cell filter pattern header?byte 1 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx user cell header pattern?byte 1 r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 104 for more information on the user cell filter, please see section 7.2.2.3.2. 3.3.2.109?rx cp user cell filter pattern header?byte 2 the user (or assigned) cell filtering criteria is defined based upon the contents of 8 read/write registers. these reg- isters are the four ?rx cp user cell filter pattern header byte? registers, and the four ?rx cp user cell filter mask header byte? registers. this ?read/write? register, along with the ?rx cp user cell filter mask header?byte 2? register (address = 6fh) allows the user to define the user (or assigned) cell filtering criteria for octet 2 of the incoming user cell. the user will write in the header byte pattern for octet 2, that he/she wishes to use as part of the user cell filtering criteria, into this register. the user will also write in a value to the ?rx cp user cell filter mask heade?byte 2? register, that indicates which bits within the second octet of the incoming cell are to be compared with the contents of this register. for more information on the user cell filter, please see section 7.2.2.3.2. 3.3.2.110?rx cp user cell filter pattern header?byte 3 the user (or assigned) cell filtering criteria is defined based upon the contents of 8 read/write registers. these reg- isters are the four ?rx cp user cell filter pattern header byte? registers, and the four ?rx cp user cell filter mask header byte? registers. this ?read/write? register, along with the ?rx cp user cell filter mask header?byte 3? register (address = 70h) allows the user to define the user (or assigned) cell filtering criteria for octet 3 of the incoming user cell. the user will write in the header byte pattern for octet 3, that he/she wishes to use as part of the user cell filtering criteria, into this register. the user will also write in a value to the ?rx cp user cell filter mask header?byte 3? register, that indicates which bits within the third octet of the incoming cell are to be compared with the contents of this register. address = 6bh, rx cp user cell filter pattern header?byte 2 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx user cell header pattern?byte 2 r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0 address = 6ch, rx cp user cell filter pattern header?byte 3 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx user cell header pattern?byte 3 r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 105 for more information on the user cell filter, please see section 7.2.2.3.2. 3.3.2.111?rx cp user cell filter pattern header?byte 4 the user (or assigned) cell filtering criteria is defined based upon the contents of 8 read/write registers. these reg- isters are the four ?rx cp user cell filter pattern header byte? registers, and the four ?rx cp user cell filter mask header byte? registers. this ?read/write? register, along with the ?rx cp user cell filter mask header?byte 4? register (address = 71h) allows the user to define the user (or assigned) cell filtering criteria for octet 4 of the incoming user cell. the user will write in the header byte pattern for octet number 4, that he/she wishes to use as part of the user cell filtering criteria, into this register. the user will also write in a value to the ?rx cp user cell filter mask header?byte 4? register, that indicates which bits within the fourth octet of the incoming cell are to be compared with the contents of this register. for more information on the user cell filter, please see section 7.2.2.3.2. 3.3.2.112?rx cp user cell filter mask header?byte 1 this ?read/write? register allows the user to specify which bit(s), in octet 1 of the incoming user cell (in the receive cell processor) are to be checked against the corresponding bit(s) in the ?rx cp user cell filter pattern header? byte 1? register (address = 6ah) by the user cell filter, when determining whether a given user cell is to be filtered out or written to the rx fifo. writing a ?1? into a particular bit-field in this register, forces the user cell filter to check and compare the correspond- ing bit within octet 1 of the incoming user cell with the corresponding bit-field in the ?rx cp user cell filter pattern header?byte 1? register. writing a ?0? into a particular bit-field, causes the user cell filter to treat the corresponding bit within octet 1 in the incoming user cell as a ?don?t care? (e.g., to forgo the comparison between the corresponding bit-field in octet 1 of the incoming user with the corresponding bit in the ?rx cp user cell filter pattern header?byte 1? register.) address = 6dh, rx cp user cell filter pattern header - byte 4 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx user cell header pattern?byte 4 r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0 address = 6eh, rx cp user cell filter mask header?byte 1 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx user cell mask header?byte 1 r/w r/w r/w r/w r/w r/w r/w r/w 1 1 1 1 1 1 1 1
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 106 for more information on user cell filtering, please see section 7.2.2.3.2. 3.3.2.113?rx cp user cell filter mask header?byte 2 this ?read/write? register allows the user to specify which bit(s), in octet 2 of the incoming user cell (in the receive cell processor) are to be checked against the corresponding bit(s) in the ?rx cp user cell filter pattern header? byte 2? register (address = 6bh) by the user cell filter, when determining whether a given user cell is to be filtered out or written to the rx fifo. writing a ?1? into a particular bit-field in this register, forces the user cell filter to check and compare the correspond- ing bit within octet 2 of the incoming user cell with the corresponding bit in the ?rx cp user cell filter pattern header?byte 2? register. writing a ?0? into a particular bit-field, causes the user cell filter to treat the corresponding bit within octet 2 in the incoming user cell as a ?don?t care? (e.g., to forgo the comparison between the corresponding bit within octet 2 of the incoming user with the corresponding bit-field within the ?rx cp user cell filter pattern header - byte 2? register.) for more information on user cell filtering, please see section 7.2.2.3.2. 3.3.2.114?rx cp user cell filter mask header?byte 3 this ?read/write? register allows the user to specify which bit(s), in octet 3 of the incoming user cell (in the receive cell processor) are to be checked against the corresponding bit(s) in the ?rx cp user cell filter pattern header? byte 3? register (address = 6ch) by the user cell filter, when determining whether a given user cell is to be filtered out or written to the rx fifo. writing a ?1? into a particular bit-field in this register, forces the user cell filter to check and compare the correspond- ing bit within octet 3 of the incoming user cell with the corresponding bit in the ?rx cp user cell filter pattern header?byte 3? register. writing a ?0? into a particular bit-field, causes the user cell filter to treat the corresponding bit within octet 3 in the incoming user cell as a ?don?t care? (e.g., to forgo the comparison between the corresponding bit in octet 3 of the incoming user with the corresponding bit-field in the ?rx cp user cell filter pattern header?byte 3? register.) address = 6fh, rx cp user cell filter mask header?byte 2 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx user cell mask header?byte 2 r/w r/w r/w r/w r/w r/w r/w r/w 1 1 1 1 1 1 1 1 address = 70h, rx cp user cell filter mask header?byte 3 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx user cell mask header?byte 3 r/w r/w r/w r/w r/w r/w r/w r/w 1 1 1 1 1 1 1 1
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 107 for more information on user cell filtering, please see section 7.2.2.3.2. 3.3.2.115?rx cp user cell filter mask header?byte 4 this ?read/write? register allows the user to specify which bit(s), in octet 4 of the incoming user cell (in the receive cell processor) are to be checked against the corresponding bit(s) in the ?rx cp user cell filter pat- tern header?byte 4? register (address = 6dh) by the user cell filter, when determining whether a given user cell is to be filtered out or written to the rx fifo. writing a ?1? into a particular bit-field in this register, forces the user cell filter to check and compare the corre- sponding bit in octet 4 of the incoming user cell with the corresponding bit in the ?rx cp user cell filter pattern header?byte 4? register. writing a ?0? to a particular bit, causes the user cell filter to treat the corresponding bit within octet 4 in the incoming user cell as a ?don?t care? (e.g., to forgo the comparison between the corresponding bit in octet 4 of the incoming user with the corresponding bit-field in the ?rx cp user cell filter pattern header?byte 4? regis- ter.) for more information on user cell filtering, please see section 7.2.2.3.2. 3.3.2.116?tx cp control/interrupt register the transmit cell processor control register allows the user to control many aspect of the operation of the transmit control processor. the description of each bit-field, within this register follows. bit 7?scrambler enable this ?read/write? bit-field allows the user to enable or disable the cell scrambler, within the transmit cell pro- cessor. when the cell scrambler is enabled, it will ?scramble? the payload bytes of each cell prior to its trans- mittal to the transmit e3 framer. when the cell scrambler is disabled, then the transmit cell processor will not scramble the payload portion of each cell. instead, the transmit cell processor will transmit cells to the trans- mit e3 framer, with the cell payload data as received from the tx fifo. writing a ?0? to this bit-field disables the cell scrambler. writing a ?1? enables the cell scrambler. for more information on the cell scrambler, please see section 6.2.2.2. bit 6?coset enable this ?read/write? bit-field allows the user to enable or disable the modulo-2 addition of the coset polynomial, address = 71h, rx cp user cell filter mask header?byte 4 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx user cell mask header?byte 4 r/w r/w r/w r/w r/w r/w r/w r/w 1 1 1 1 1 1 1 1 address = 72h, tx cp control/interrupt register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 scram- bler enable coset enable hec insert enable tdp check pattern gfc insert enable tdp error interrupt enable idle cell hec calc enable tdp error interrupt status r/w r/w r/w r/w r/w r/w r/w rur 1 1 1 1 0 0 1 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 108 x6+x4 + x2 + 1 to a newly computed hec byte. once this polynomial has been added to the existing hec byte, this new modification to the contents of the hec byte, will now be referred to as the ?hec byte?. writing a ?0? to this bit-field disables this addition. writing a ?1? to this bit-field enables this addition. for more information into the function/purpose of the coset polynomial, please see section 6.2.2.1.3. bit 5?hec byte insert enable?assigned cells this ?read/write? bit-field allows the user to enable or disable the calculation and insertion of the hec byte into user or assigned cells. writing a ?0? into this bit-field disables the transmit cell processor from calculating and inserting the hec byte into each outgoing user or assigned cell. writing a ?1? into this bit-field enables this feature. for more information on this bit selection, please see section 6.2.2.1.1. bit 4?tdpchk pat (transmit data path integrity check pattern selection) the transmit cell processor is always checking for a specific (data path integrity check) pattern in the fifth octet of each cell that it reads from the tx fifo. this pattern will exist in the 5th octet of the cell, prior to the insertion of the hec byte. this ?read/write? bit-field allows the user to specify the octet pattern that the trans- mit cell processor should be checking for. the following table relates the contents of this bit field to the octet pattern expected by the transmit cell processor. for more information on this feature, please see section 6.2.2.6. bit 3?gfc nibble-field insert enable this ?read/write? bit-field allows the user to enable or disable the ?transmit gfc nibble field? serial input port (txgfc). if the user enables this input port, then he/she can externally insert the value of the gfc nibble-field into each outbound valid (e.g., user or oam) cell. if this port remains disabled, then the gfc nibble field value will remain as written into the transmit utopia interface block, by the atm layer processor. writing a ?0? into this bit-field disables this serial port. writing a ?1? into this bit-field enables this serial port. note: the ?transmit gfc nibble-field? serial input port will not insert the gfc nibble-field value into idle cells. for more information on this bit selection, please see section 6.2.2.3. bit 2? tdp (transmit data path integrity test) error interrupt enable this ?read/write? bit-field allows the user to enable or disable the ?data path integrity test? interrupt. writing a ?0? to this bit-field disables this interrupt. likewise, writing a ?1? to this bit-field enables this interrupt. bit 1?ic (idle cell) hec byte calculation enable this ?read/write? bit allows the user to enable or disable the calculation and the insertion of the hec byte into each outbound idle cell. writing a ?0? into this bit-field disables the ?hec byte calculation and insertion into idle cells? feature. writing a ?1? into this bit-field enables this feature. note: if this feature is disable, then the transmit cell processor will, instead, write the contents of the ?tx cp idle cell pattern header byte 5? register (address = 7ah) into the fifth octet position of each idle cell. for more details into the operation of idle cells, please see section 6.2.2.1.2. tdpchk pat result 0 transmit cell processor expects an alternating ?55h?/?aah? pattern for the value of the fifth octet of the cells received from the tx fifo. 1 transmit cell processor expects a constant ?55h? pattern for the value of the fifth octet of the cells received from the tx fifo.
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 109 bit 0?tdp (transmit data path integrity check) error interrupt status this ?reset-upon-read? bit-field indicates whether or not the ?data path integrity test? interrupt has occurred since the last reading of the tx cp control register. this interrupt will occur if the transmit cell processor detects a byte- pattern, in the fifth octet position of a cell read from the txfifo, that differs from the expected ?data path integrity check? pattern. a ?1? in this bit-field indicates that this interrupt has occurred since the last reading of the tx cp control register. a ?0? in this bit-field indicates that this interrupt has not occurred. for more details on the data path integrity check, please see section 6.2.2.6. 3.3.2.117?tx cp oam cell register bit 7?send oam (cell) a ?0? to ?1? transition in this bit-field will cause the transmit cell processor to read in the contents of the ?transmit oam cell buffer? (located at 136h through 16bh in on-chip ram), and transmit this information as a cell to the transmit e3 framer. for more information on oam cell processing please see section 6.2.2.4. 3.3.2.118?tx cp hec byte error mask register this ?read/write? byte-field allows the user to insert errors into the hec byte of each ?outbound? cell (from the transmit cell processor block). prior to transmission to the transmit e3 framer, the transmit cell processor will perform an xor operation with the hec byte of each cell and the contents of this register; and will write the results of this operation back into the 5th octet position of each cell. therefore, if the user does not wish to insert errors into the hec byte of each cell, he/she should insure that the contents of this register is set to ?00h? (the default value). for more information in the purpose/use of this register, please see section 6.2.2.1.4. address = 73h, tx cp oam cell register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 send oam unused sem. ro ro ro ro ro ro ro 0 0 0 0 0 0 0 0 address = 74h, tx cp hec byte error mask register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 hec error mask r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 110 3.3.2.119?future use 3.3.2.120?tx cp idle cell pattern header?byte 1 this ?read/write? byte-field allows the user to specify the contents of the first header byte of the idle cells that are to be generated by the transmit cell processor. the default value of this byte is 00h. 3.3.2.121?tx cp idle cell pattern header?byte 2 this ?read/write? byte-field allows the user to specify the contents of the second header byte of the idle cells that are to be generated by the transmit cell processor. the default value of this byte is 00h. 3.3.2.122? tx cp idle cell pattern header?byte 3 address = 75h, future use bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 address = 76h, tx cp idle cell pattern header?byte 1 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 tx idle cell pattern header?byte 1 r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0 address = 77h, tx cp idle cell pattern header?byte 2 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 tx idle cell pattern header?byte 2 r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0 address = 78h, tx cp idle cell pattern header - byte 3 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 tx idle cell pattern header?byte 3
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 111 this ?read/write? byte-field allows the user to specify the contents of the third header byte of the idle cells that are to be generated by the transmit cell processor. the default value of this byte is 00h. 3.3.2.123? tx cp idle cell pattern header?byte 4 this ?read/write? byte-field allows the user to specify the contents of the first header byte of the idle cells that are to be generated by the transmit cell processor. the default value of this byte is 01h. 3.3.2.124?tx cp idle cell pattern header?byte 5 this ?read/write? byte-field allows the user to specify the contents of the fifth header byte of the idle cells that are to be generated by the transmit cell processor. the default value of this byte is 52h. note: if the user enables the ?idle cell hec byte calculation enable? features, then the transmit cell proces- sor will compute and insert the hec byte into the 5th octet position, in lieu of using the contents of this register. 3.3.2.125?tx cp idle cell payload register this ?read/write? byte-field allows the user to specify the contents of the payload portion of the idle cells that are to be generated by the transmit cell processor. the default value of this byte is 5ah. note: the payload portion of each idle cell will consist of contents of this register, replicated 48 times. r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0 address = 79h, tx cp idle cell pattern header - byte 4 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 tx idle cell pattern header?byte 4 r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 1 address = 7ah, tx cp idle cell pattern header?byte 5 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 tx idle cell pattern header?byte 5 r/w r/w r/w r/w r/w r/w r/w r/w 0 1 0 1 0 0 1 0 address = 7bh, tx cp idle cell payload register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 tx idle cell pattern?payload byte r/w r/w r/w r/w r/w r/w r/w r/w 0 1 0 1 1 0 1 0 address = 78h, tx cp idle cell pattern header - byte 3
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 112 3.3.2.126?utopia configuration register this register allows the user to control many aspects of the operation of the transmit utopia interface block. the description of each of these bit-fields within this registers follows. bit 5?handshake mode this ?read/write? bit-field allows the user to configure the transmit and receive utopia interface blocks to operate in either the ?octet level? or ?cell level? handshake modes. writing a ?0? to this bit-field configures both the transmit and receive utopia interface blocks to operate in the ?octet- level? handshake mode. writing a ?1? to this bit-field configures both of these blocks to operate in the ?cell level? handshake mode. for more information on ?octet-level? and ?cell-level? handshake mode operations, please see section 6.1.2.2.1. bit 4?s-phy/m-phy* (utopia operating mode) this ?read/write? bit-field allows the user to configure the uni chip to operate in either the single-phy or multi-phy modes. when the uni chip is operating in single phy mode, it is configured such that the atm layer processor will be writing atm cell data to and reading atm cell data from it, and no other uni ics. consequently, in single phy mode, the uni ic will not be checking for a valid address on the utopia address bus. it will simply support read and write operations, with the atm layer processor, based upon the utopia data bus signal (e.g., txenb, txsoc, txclav, rxenb, rxsoc and rxclav). when the uni chip is operating in multi-phy mode, it is now configured such that the atm layer processor will be writing atm cell data to and reading atm cell data from it and, possibly numerous other uni ics. therefore, in this mode, the uni ic will be checking for a valid address, on the utopia address bus, prior to performing any reads or writes from the atm layer processor. unless the uni ic detects it own address, on the utopia address bus, it will ignore the utopia data bus signals (e.g., txenb, txsoc, txclav, rxenb). writing a ?0? to this bit-field will configure the uni to operate in the multi-phy mode. writing a ?1? to this bit-field will configure the uni to operate in the single-phy mode. this configuration selection applies to both the transmit utopia interface and receive utopia interface blocks. the default utopia operating mode is multi-phy. for more information on single-phy and multi-phy operation, please see section 6.1.2.3. bit 3?cellof52bytes this ?read/write? bit-field allows the user to configure the cell size (e.g., number of octets per cell) that the trans- mit and receive utopia interface blocks will process over the transmit and receive utopia data buses; as summa- address = 7ch, utopia configuration register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused hand shake mode sphy/ mphy* cellof 52 bytes txfifo depth[1] txfifo depth[0] utopia width16 ro ro r/w r/w r/w r/w r/w r/w 0 0 1 0 0 0 0 0
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 113 rized below. for more information on this parameter, please see sections 6.1.2.1.3. bits 2, 1,?tfifodepth[1, 0] these two ?read/write? bit-fields allows the user to configure the operating depth of the tx fifo; as summarized below bit 0?utwidth16?utopia data width this ?read/write? bit-field allows the user to configure the width of the utopia data bus (for both the transmit and receive utopia interface blocks) to be either 8 bits or 16 bits. writing a ?0? to this bit-field will configure the utopia data bus width (for both transmit and receive directions) to be 8 bits. writing a ?1? to this bit-field will configure the utopia data bus width to be 16 bits. for more information into this option, please see section 6.1.2.1.2. 3.3.2.127?receive utopia interrupt enable/status register cellof52bytes number of octets per cell 0 53 bytes?when the utopia data bus width is configured to be 8 bits 54 bytes?when the utopia data bus width is configured to be 16 bits 1 52 bytes?independent of the configured utopia data bus width txfifodepth[1, 0] operating depth of tx fifo 00 16 cells 01 12 cells 10 8 cells 11 4 cells address = 7dh, rx ut interrupt enable/status register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused rxfifo reset rxfifo overflw interrupt enable unused rcoca interrupt enable rxfifo overflw interrupt status unused rcoca interrupt status ro r/w r/w ro r/w ro ro rur 0 0 0 0 0 0 0 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 114 bit 6?rxfifo reset this ?read/write? bit-field allows the user to command a reset of the rxfifo, within the receive utopia inter- face block; without having to command a reset of the entire chip. commanding a reset of the rxfifo will clear out all of its contents. additionally, it will reset the pointer to cells within the rxfifo. writing a ?1? to this bit-field will cause the rx fifo to be reset. bit 5?rxfifo overrun interrupt enable this ?read/write? bit-field allows the user to enable or disable the ?rx fifo overrun condition? interrupt. writing a ?0? to this bit-field disables this interrupt. writing a ?1? to this bit-field enables this interrupt. bit 3?rcoca interrupt enable this ?read/write? bit-field allows the user to enable or disable the ?rx fifo change of cell alignment? inter- rupt. writing a ?0? to this bit-field disables this interrupt. writing a ?1? to this bit-field enables this interrupt. bit 2?rxfifo overrun interrupt status this ?read-only? bit-field indicates whether or not the ?rx fifo overrun condition? interrupt has occurred since the last read of this register. a ?0? in this bit-field indicates that the ?rx fifo overrun condition? interrupt has not occurred since the last read of this register. a ?1? in this bit-field indicates that the ?rx fifo overrun condition? interrupt has occurred since the last read of this register. note: this bit-field is only cleared if the rxfifo has been depleted. for more information on this interrupt condition, please see section 7.3.2.3. bit 0?rcoca (receive utopia interface block - change of cell alignment) interrupt status this ?reset-upon-read? bit-field indicates whether or not the ?rx fifo change of cell alignment interrupt has occurred since the last read of this register. a ?0? in this bit-field indicates that the ?rx fifo change of cell alignment? interrupt has not occurred since the last read of this register. a ?1? in this bit-field indicates that the ?rx fifo change of cell alignment? interrupt has occurred since the last read of the register. for more information on this interrupt condition, please see section 7.3.2.3. 3.3.2.128?receive utopia address register bits 4 through 0 of this register are ?read/write? bit-fields that allows the user to assign a specific ?utopia address? value to this receive utopia interface block. this register is only important when the uni is running in multi-phy operation. for more information on this register and the receive utopia address bus, please see section 7.3.2.2.2.2. address = 7eh, receive utopia address register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused receive utopia address ro ro ro r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 115 3.3.2.129?receive utopia fifo status register bit 1?rxfifo full this ?read-only? bit-field indicates whether or not the rx fifo (within the receive utopia interface block) is full. ifthis bit-field is ?0?, then the rx fifo is not full. however, if this bit-field is ?1?, then the rx fifo is full. bit 0?rxfifo empty this ?read-only? bit-field indicates whether or not the rx fifo (within the receive utopia interface block) is empty. if this bit-field is ?0?, then the rx fifo is not empty. however, if this bit-field is ?1?, then the rx fifo is empty. 3.3.2.130?transmit utopia interrupt/status register bit 7? txfifo reset this ?read/write? bit-field allows the user to command a reset of the txfifo, within the transmit utopia inter- face block; without having to command a reset of the entire chip. writing a ?1? to this bit-field will cause the tx fifo to be reset. bit 6?discard (cell) upon parity error (transmit utopia interface block) this ?read/write? bit-field allows the user to configure the transmit utopia interface block to discard or retain cells containing parity error(s), as detected by the transmit utopia interface block. writing a ?0? to this bit-field configures the transmit utopia interface block to retain all cells (including the errored cells) and ultimately write these cells into the tx fifo. writing a ?1? to this bit-field configures the transmit utopia interface block to dis- card every cell that contains a parity error. for more information on this selection please see section 6.1.2.1.4. bit 5?tx parity interrupt enable (transmit utopia interface block) this ?read/write? bit-field configures the transmit utopia interface block to generate the ?detection of parity error? interrupt, if it detects a parity error on the transmit utopia data bus. writing a ?0? to this bit-field disables this interrupt. writing a ?1? to this bit-field enables this interrupt. bit 4?txfifo overrun interrupt enable this ?read/write? bit-field configures the transmit utopia interface block to generate the ?tx fifo overrun rx ut fifo status register (address = 7fh) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused rxfifo full rxfifo empty ro ro ro ro ro ro ro ro 0 0 0 0 0 0 0 1 address = 80h, tx ut interrupt/status register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 txfifo reset discard upon parity error tx parity interrupt enable txfifo overflw interrupt enable tcoca interrupt enable tx parity interrupt status txfifo overflw interrupt status tcoca interrupt status r/w r/w r/w r/w r/w rur rur rur 0 0 0 0 0 0 0 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 116 condition? interrupt if it detects an overrun condition in the txfifo. writing a ?0? to this bit-field disables this interrupt. writing a ?1? to this bit-field enables this interrupt. bit 3?txfifo change of cell alignment interrupt enable this ?read/write? bit-field configures the transmit utopia interface block to generate the ?tx fifo change of cell alignment? interrupt if it detects the receipt of a ?runt? cell. writing a ?0? to this bit-field disables this interrupt. writing a ?1? to this bit-field enables this interrupt. bit 2?tx parity interrupt status this ?reset-upon-read? bit-field indicates whether or not the ?detection of parity error condition (tx utopia)? interrupt has occurred since the last read of this register. a ?0? in this bit-field indicates that the ?detection of parity error condition? interrupt has not occurred since the last read of this register. a ?1? in this bit-field indicates that the ?detection of parity error condition? interrupt has occurred since the last read of this register. for more information on this interrupt condition, please see section 6.1.2.1.4. bit 1?txfifo overrun interrupt status this ?reset-upon-read? bit-field indicates whether or not the ?tx fifo overrun condition? interrupt has occurred since the last read of this register. a ?0? in this bit-field indicates that the ?tx fifo overrun condition? interrupt has not occurred since the last read of this register. a ?1? in this bit-field indicates that the ?tx fifo overrun condition? interrupt has occurred since the last read of thisregister. for more information on this interrupt condition, please see section 6.1.2.4. bit 0?txfifo change of cell alignment interrupt status this ?reset-upon-read? bit-field indicates whether or not the ?tx fifo change of cell alignment? interrupt has occurred since the last read of this register. a ?0? in this bit-field indicates that the ?tx fifo change of cell alignment? interrupt has not occurred since the last read of this register. a ?1? in this bit-field indicates that the ?tx fifo change of cell alignment? interrupt has occurred since the last read of the register. this interrupt will occur if the transmit utopia interface block detects a ?runt? cell. for more information on this interrupt condition, please see section 6.1.2.4. 3.3.2.131?future use address = 81h, future use bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 0 0 0 0 0 0 0 0
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 117 3.3.2.132?transmit utopia address register bits 4 through 0 of this register are ?read/write? bit-fields that allows the user to assign a specific ?utopia address? value to this transmit utopia interface block. this register is only important when the uni is running in multi-phy operation. for more information on this register and the transmit utopia address bus, please see section 6.1.2.3.2. 3.3.2.133?transmit utopia fifo status register bit 1?txfifo full this ?read only? bit-field indicates whether or not the tx fifo (within the transmit utopia interface block) is full. if this bit-field contains a ?0? then the tx fifo is not full. if this bit-field contains a ?1?, then the tx fifo is full. bit 0?txfifo empty this ?read only? bit-field indicates whether or not the tx fifo (within the transmit utopia interface block) is empty. if this bit-field contains a ?0? then the tx fifo is not empty. if this bit-field contains a ?1?, then the tx fifo is empty. 3.3.2.134?line interface drive register bit 5?reqb (receive equalization bypass control) this ?read/write? bit-field allows the user to control the state of the reqb output pin of the uni device. this output pin is intended to be connected to the reqb input pin of the xr-t7295e e3 line receiver ic. if the user forces this address = 82h, transmit utopia address register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused transmit utopia address[4:0] ro ro ro r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0 address = 83h, transmit utopia fifo status register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused txfifo full txfifo empty ro ro ro ro ro ro ro ro 0 0 0 0 0 0 0 1 address = 84h, line interface drive register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused reqb taos encodis txlev rloop lloop ro ro r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 118 signal to toggle ?high?, then the xr-t7295e device will cause its newly received e3 line signal to ?by-pass? some equalization circuitry within the xr-t7295e device. conversely, if the user forces this signal to toggle ?low?, then the xr-t7295e device will route its newly received e3 line signal through its internal equalization circuitry. writing a ?1? to this bit-field causes the uni device to toggle the reqb output pin ?high?. writing a ?0? to this bit-field causes the uni device to toggle the reqb output pin ?low?. for information on the criteria that should be used when deciding whether to bypass the equalization circuitry or not, please consult the ?xr-t7295e e3 integrated line receiver? data sheet. note: if the customer is not using the xr-t7295e e3 line receiver ic, then he/she can use this bit-field and the reqb output pin for other purposes. bit 4?taos (transmit all ones signal) this ?read/write? bit-field allows the user to control the state of the taos output pin of the uni device. this output pin is intended to be connected to the taos input pin of the xr-t7296 e3 line transmitter ic. if the user forces this signal to toggle ?high?, then the xr-t7296 device will transmit an ?all ones? pattern onto the line. conversely, if the user commands this output signal to toggle ?low? then the xr-t7296 e3 line transmitter ic will proceed to transmit data based upon the pattern that it receives via the txpos and txneg output pins (of the uni ic). writing a ?1? to this bit-field will cause the taos output pin to toggle ?high?. writing a ?0? to this bit-field will cause this output pin to toggle ?low?. note: if the customer is not using the xr-t7296 e3 line transmitter ic, then he/she can use this bit-field, and the taos output pin for other purposes. bit 3?encodis (hdb3 encoder disable) this ?read/write? bit-field allows the user to control the state of the encodis output pin of the uni device. this output pin is intended to be connected to the encodis input pin of the xr-t7296 e3 line transmitter ic. if the user forces this signal to toggle ?high?, then the ?internal hdb3 encoder? (within the xr-t7296 device) will be disabled. conversely, if the user command this output signal to toggle ?low?, then the ?internal hdb3 encoder? (within the xr-t7296 device) will be enabled. writing a ?1? to this bit-field causes the uni ic to toggle the ?encodis? output pin ?high?. writing a ?0? to this bit-field will cause the uni ic to toggle this output pin ?low?. note: 1. the hdb3 encoder, within the xr-t7296 device, is not to be confused with the hdb3 encoding capable that exists within the transmit e3 framer block of the uni ic. 2. the user is advised to disabled the hdb3 encoder (within the xr-t7296 ic) if the transmit and receive e3 framers (within the uni) are configured to operate in the hdb3 line code. 3. if the customer is not using the xr-t7296 e3 line transmitter ic, then he/she can use this bit-field and the ?encodis? output pin for other purposes. bit 2?txlev (transmit level select output) this ?read/write? bit-field allows the user to control the state of the ?txlev? output pin of the uni device. this output pin is intended to be connected to the txlev input pin of the xr-t7296 e3 line transmitter ic. if the user commands this signal to toggle ?high?, then the xr-t7296 e3 line transmitter ic will increase the amplitude of its output signal on the line, in order to drive the signal over cable lengths of 225 ft or greater. therefore, the user is recommended to set this output high, if he/she is driving e3 lines signal over 225 ft (or more) of cable.
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 119 conversely, if the user is driving e3 line signals over less than 225 ft of cable, then he/she is recommended to set this output pin low. writing a ?1? to this bit-field commands the uni to toggle the txlev output ?high?. writing a ?0? to this bit-field com- mands the uni to toggle this output signal ?low?. note: if the customer is not using the xr-t7296 e3 line transmitter ic, then he/she can use this bit-field and the txlev output pin for other purposes. bit 1?rloop (remote loopback) this ?read/write? bit-field allows the user to control the state of the rloop output pin of the uni device. this output pin is intended to be connected to the rloop input pin of the xr-t7296 e3 line transmitter ic. if the user commands this signal to toggle ?high?, then the xr-t7296 e3 line transmitter ic will start operating in the ?remote loopback mode?. conversely, if the user commands this signal to toggle ?low?, then the xr-t7296 device will be operating in the ?normal? mode. writing a ?1? into this bit-field commands the uni to toggle the ?rloop? output signal ?high?. writing a ?0? into this bit-field commands the uni to toggle this output signal ?low?. for a detailed description of the xr-t7296 e3 line transmitter?s operation during ?remote loopback?, please see the ?xr-t7296 e3/sts-1, e3 integrated line transmitter?s data sheet. note: if the customer is not using the xr-t7296 e3 line transmitter ic, then he/she can use this bit-field and the rloop output pin for other purposes. bit 0? lloop this ?read/write? bit-field allows the user to control the state of the lloop output pin of the uni device. this output pin is intended to be connected to the lloop input pin of the xr-t7296 e3 line transmitter ic. if the user commands this signal to toggle ?high?, then the xr-t7296 e3 line transmitter ic will start operating in the ?local loopback mode?. conversely, if the user commands this signal to toggle ?low?, then the xr-t7296 device will be operating in the ?normal? mode. writing a ?1? into this bit-field commands the uni to toggle the ?lloop? output signal ?high?. writing a ?0? into this bit-field commands the uni to toggle this output signal ?low?. for a detailed description of the xr-t7296 e3 line transmitter?s operation during ?local loopback?, please see the ?xr-t7296 e3/sts-1, e3 integrated line transmitter?s data sheet. note: if the customer is not using the xr-t7296 e3 line transmitter ic, then he/she can use this bit-field and the lloop output pin for other purposes. 3.3.2.135?line interface scan register bit 2?dmo (drive monitor output) this ?read-only? bit-field indicates the logic state of the dmo input pin of the uni device. this input pin is intended to be connected to the dmo output pin of the xr-t7296 e3 line transmitter ic. if this bit-field con- tains a logic ?1?, then the dmo input pin is ?high?. the xr-t7296 e3 line transmitter ic will set this pin ?high? if the drive monitor circuitry (within the xr-t7296 device) has not detected any bipolar signals at the mtip and mring inputs (of the xr-t7296 device) within the last 128 32 bit periods. conversely, if this bit-field contains a logic ?0?, then the dmo input pin is ?high?. the xr-t7296 e3 line trans- address = 85h, line interface scan register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused dmo rlol rlos ro ro ro ro ro ro ro ro 0 0 0 0 0 0 0 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 120 mitter ic will set this pin ?low? if bipolar signals are being detected at the mtip and mring input pins. note: if this customer is not using the xr-t7296 e3 line transmitter ic, then he/she can use this input pin for a variety of other purposes. bit 1?rlol (receive loss of lock) this ?read-only? bit-field indicates the logic state of the rlol input pin of the uni device. this input pin is intended to be connected to the rlol output pin of the xr-t7295e e3 line receiver ic. if this bit-field contains a logic ?1?, then the rlol input pin is ?high?. the xr-t7295e e3 line receiver ic will set this pin ?high? if the phase-locked- loop circuitry (within the xr-t7295e device) has lost ?lock? with the incoming e3 data-stream and is not properly recovering clock and data. conversely, if this bit-field contains a logic ?0?, then the rlol input pin is ?low?. the xr-t7295e e3 line receiver ic will hold this pin ?low? as long as this ?phase-locked-loop? circuitry (within the xr-t7295e device) is properly ?locked? onto the incoming e3 data-stream, and is properly recovering clock and data from this data-stream. for more information on the operation of the xr-t7295e e3 line receiver ic, please consult the ?xr-t7295e e3 integrated line receiver? data sheet. note: if the customer is not using the xr-t7295e e3 line receiver ic, then he/she can use this bit-field, and the rlol input pin for other purposes. bit 0?rlos (receive loss of signal) this ?read-only? bit-field indicates the logic state of the rlos input pin of the uni device. this input pin is intended to be connected to the rlos output pin of the xr-t7295e e3 line receiver ic. if this bit-field contains a logic ?1?, then the rlos input pin is ?high?. the xr-t7295e device will toggle this signal ?high? if it (the xr-t7295e e3 line receiver ic) is not detecting a sufficient amount of signal energy on the line, from the incoming e3 data-stream. this event indicates that the xr-t7295e device may be experiencing a loss of signal (los) condition. conversely, if this bit-field contains a logic ?0?, then the rlos input pin is ?low?. the xr-t7295e device will hold this signal ?low? if it is detecting a sufficient amount of signal energy on the line, from the incoming e3 data-stream. for more information on the operation of the xr-t7295e e3 line receiver ic, please consult the ?xr-t7295 e3 integrated line receiver? data sheet. 3.4 the ?loss of clock enable? feature the timing for the microprocessor interface section is asynchronous to the 34.368 mhz signal, which is applied to either the rxlineclk or the txinclk input pins. however, the ?on-chip? registers are updated by circuitry that is driven by one of these two clock signals. hence, if the uni device experiences a ?loss of clock signal? event such that neither the txinclk nor the rxlineclk signal are present, then the read or write operations with the uni micro- processor interface section could cease to function. in order to prevent this phenomenon, the uni device offers a ?loss of clock? (loc) protection feature that allows the microprocessor interface section to at least complete or terminate an ?in-process? read or write cycle (with the local m p ) should this ?loss of clock? event occur. the ?loc? circuitry consists of a ring oscillator that continuously checks for signal transitions at the txinclk and rxlineclk input pins. if a ?loss of clock? signal event occurs such that no transitions are occurring on these pins, then the loc circuitry will automatically assert the rdy_dtck signal in order to complete (or terminate) the current ?read? or ?write? cycle with the uni microprocessor interface sec- tion. the user may enable or disable this ?loc protection? feature by writing to bit 6 (disable loc) within the ?uni
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 121 operating mode? register, as depicted below. writing a ?1? to this bit-field disables this ?loc protection? feature. writing a ?0? to this bit-field enables this feature. note: the ?ring oscillator? can be a source of noise, within the uni chip. hence, there may be a situation where the user will wish to disable the ?loc protection? feature. 3.5 using the pmon holding register if the microprocessor interface section is configured to operate over an 8-bit data bus; then the local m p will be able to read from and write to the uni on-chip registers, 8 bit per (read or write) cycle. since most of the uni on-chip registers contain 8-bits; communicating with the local m p , over an 8-bit data bus, is not much of an inconvenience. however, all of the pmon registers, within the uni ic, contain 16 bits. consequently, any reads of the pmon registers, will require two read cycles. the XR-T7234 e3 uni includes a feature that will make reading a pmon register a slightly less complicated task. the uni chip address space contains a register known as the ?pmon holding? register, which is located at 56h. whenever the local m p (while operating over an 8-bit data bus with the microprocessor interface of the uni) reads in an 8-bit value of a given pmon registers (e.g., either the upper-byte or the lower byte value of the pmon register); the other 8-bit value of that pmon register will automatically be accessible by reading the pmon holding register. hence, whenever the microprocessor interface is configured to operate over an 8-bit data bus, anytime the local m p is trying to read in the contents of a pmon register; the first read access must be made directly to one of the 8-bit values of the pmon registers (e.g., for example: the pmon received single-bit hec error count - msb, address = 48h). however, the second read can always be made to a constant location in system memory; the pmon holding register. 3.6 the interrupt structure within the uni microprocessor interface section the XR-T7234 uni device is equipped with a sophisticated interrupt servicing structure. this interrupt structure includes an interrupt request output, int*, numerous interrupt enable registers and numerous interrupt status registers. the interrupt servicing structure, within the uni contains two levels of hierarchy. the top level is at the ?functional block? level (e.g., the receive e3 framer, transmit e3 framer, receive cell processor, etc.) the lower hierarchical level is at the individual interrupt or ?source? level. each hierarchical level consists of a complete set of interrupt status registers/bits and interrupt enable registers/bits, as will be discussed below. most of the functional blocks, within the uni, are capable of generating interrupt requests to the local m c/ m p . the uni device interrupt structure has been carefully designed to allow the user to quickly determine the exact source of the interrupt (with minimal latency) which will aid the local m p / m c in determining which interrupt service routine to call up in order to eliminate the condition(s) causing the interrupt. uni operating mode register (address = 00h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused disable loc int los enable reset by reg cell loopback line loopback timref sel(1) timref sel(0) r/o r/w r/w r/w r/w r/w r/w r/w 0 x 1 0 0 0 0 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 122 table 5 lists all of the possible conditions that can generate interrupts, within each functional block of the uni. the XR-T7234 uni interrupt block comes equipped with the following registers to support the servicing of this wide array of potential ?interrupt request? sources. table 6 lists these registers and their corresponding addresses, within the uni. table 5. list of all of the possible condition that can generate interrupts within the XR-T7234 uni device functional block interrupting condition transmit utopia block ? detection of parity errors ? change of cell alignment ? tx fifo overrun transmit cell processor ? data path integrity error occurrence transmit e3 framer ? lapd message frame transfer complete receive e3 framer ? change of state on receive los, oof, lof, ais detection ? change in ferf condition ? change in frame alignmentreceipt of new lapd message frame ? em (bip-8) byte errors ? febe indications detection of framing byte errors ? receipt of new trail trace buffer message ? payload type mismatch change receive cell processor ? hec byte errors ? oam cell received ? loss of cell delineation receive utopia block ? rx fifo overrun ? change of cell alignment uni chip level ? one-second interrupt table 6. a listing of the XR-T7234 uni device interrupt block registers address location register 04h uni interrupt enable register 05h uni interrupt status register
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 123 general flow of uni chip interrupt servicing when any of the conditions, presented in table 4 a occurs, (if their interrupt is enabled), then the uni will generate an interrupt request to the local m p / m c by asserting the active-low interrupt request output pin, int*. shortly after the local m p / m c has detected the activated int* signal, it will enter into the appropriate ?user-supplied? interrupt ser- vice routine. the first task for the local m p / m c, while running this interrupt service routine, may be to isolate the source of the interrupt request down to the device level (e.g., XR-T7234 uni device), if multiple peripheral devices exist in the user?s system. however, once the ?interrupting peripheral? device has been identified, the next task for the local m p / m c is to determine exactly what feature or functional section within the device requested the interrupt. determine the functional block(s) requesting the interrupt if the interrupting device turns out to be the XR-T7234 e3 uni, then the local m c/ m p must determine which ?func- tional block? (within the uni) requested the interrupt. hence, upon reaching this state, one of the very first things that the local m c/ m p must do within the user supplied ?uni? interrupt service routine, is to perform a read of the uni interrupt status register (address = 05h) within the XR-T7234 uni device. the bit format of the uni interrupt sta- tus register is presented below. the uni interrupt status register, presents the ?interrupt request? status of each functional block, within the chip. the purpose of the uni interrupt status register is to help the local m p / m c identify which functional block(s) has requested the interrupt. whichever bit(s) are asserted, in this register, identifies which block(s) have experienced an ?interrupt-generating? condition as presented in table 5. once the local m p / m c has read this register, it can deter- mine which ?branch? within the interrupt service routine that it must follow; in order to properly service this interrupt. 10h receive e3 framer interrupt enable register-1 11h receive e3 framer interrupt enable register-2 12h receive e3 framer interrupt status register-1 13h receive e3 framer interrupt status register-2 3fh transmit e3 lapd status/interrupt register 60h receive cell processor interrupt enable register 61h receive cell processor interrupt status register 72h transmit cell processor control/interrupt register 7dh receive utopia interrupt enable/status register 80h transmit utopia interrupt enable/status register uni interrupt status register: address = 05h bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused one sec. interrupt status tx e3 framer interrupt status rx e3 framer interrupt status tx cp interrupt status rx cp interrupt status tx utopia interrupt status rx utopia interrupt status ro rur ro ro ro ro ro ro table 6. a listing of the XR-T7234 uni device interrupt block registers address location register
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 124 the uni further supports the functional block hierarchy by providing the uni interrupt enable register (address = 04h). the bit format of this register is identical to that for the uni interrupt status register, and is presented below for the sake of completeness. the uni interrupt enable register allows the user to individually enable or disable the interrupt requesting capability of the functional blocks, within the uni. if a particular bit field, within this register contains the value ?0?; then the corresponding functional block has been disabled from generating any interrupt requests. conversely, if that bit field contains the value ?1?; then the corresponding functional block has been enabled for interrupt generation (e.g., those potential interrupts, within the ?enabled functional block? that are enabled at the source level, are now enabled). the user should be aware of the fact that each functional block, within the uni, contains anywhere from 1 to 12 potential interrupt sources. each of these lower level interrupt sources contain their own set of interrupt enable bits and interrupt status bits, existing in various on-chip registers. interrupt service routine branching: after reading the uni interrupt status register the contents of the uni interrupt status register identify which of 7 functional blocks (within the uni ic) have requested interrupt service. the local m p should use this information in order to determine where, within the interrupt service routine, program control should branch to. the following table can be viewed as an ?interrupt service routine? guide. it lists each of the functional blocks, that contain a bit-field in the uni interrupt status register. additionally, thistable also presents a list and addresses of corresponding on-chip registers that the interrupt service routine should branch to and read; based upon the interrupting functional block. once the local m p / m c has read the register that corresponds to the ?interrupting source? within the uni, then the fol- lowing things will happen. 1. the ?asserted interrupt status? bit-fields within this register will be reset upon read. 2. the ?asserted? bit-field, within the uni interrupt status register will be reset. uni interrupt enable register: address = 04h bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused one sec. interrupt enable tx e3 framer interrupt enable rx e3 framer inter- rupt enable tx cp interrupt enable rx cp interrupt enable tx utopia interrupt enable rx utopia interrupt enable ro r/w r/w r/w r/w r/w r/w r/w table 7. interrupt service routine guide interrupting functional block the next registers to be read during the interrupt service routine register address receive e3 framer rx e3 interrupt status register-1 12h rx e3 interrupt status register-2 13h receive cell processor rx cp interrupt status register 61h receive utopia interface rx ut interrupt enable/status register 7dh transmit utopia interface tx ut interrupt enable/status register 80h transmit cell processor tx cp register 72h transmit e3 framer tx e3 lapd status/interrupt register 3fh one second interrupt user?s option
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 125 3. the uni device will negate the int* (interrupt request) output. 3.6.1 automatic reset of interrupt enable bits occasionally, the user?s system (which includes the uni device), may experience a fault condition, such that a ?uni interrupt condition? will continuously exist. if this particular interrupt condition has been enabled (within the uni) then the uni device will generate an interrupt request to the local m p / m c. afterwards, the local m p / m c will attempt to service this interrupt by reading the uni interrupt status register and the subsequent ?source? level interrupt status register. additionally, the local m p / m c will attempt to perform some ?system-related? tasks in order to try to resolve those conditions causing the interrupt. after the local m p / m c has attempted all of these things, the uni ic will negate the int* output. however, because the system fault still remains, the conditions causing the uni to issue this interrupt request, also still exists. consequently, the uni device will generate another interrupt request, which forces the local m p / m c to ?once again? attempt to service this interrupt. this phenomenon quickly results in the local m p / m c being ?tied up? in a continuous cycle of executing this one interrupt service routine. consequently, the local m p / m c (along with portions of the overall system) now becomes non-functional. in order to prevent this phenomenon from ever occurring, the uni ic allows the user to automatically reset the ?interrupt enable? bits, following their activation. the user can implement this feature by writing the appropriate value to bit 5 (int en reset) within the uni i/o control register, as depicted below. writing a ?1? to this bit-field configures the uni to automatically disable a given interrupt, following its activation. writing a ?0? to this bit-field configures the uni to leave the ?interrupt enable? bits enabled, following interrupt activation. if a user opts to implement the ?automatic reset of interrupt enable bits? feature, then he/she might wish to configure the local m p / m c to go back and ?re-enable? these interrupts at a later time. 3.6.2 one second interrupts the uni interrupt status register, and the uni interrupt enable register each contain a bit-field for the ?one second? interrupt. if this interrupt is enabled (within the uni interrupt enable register), then the uni device will automatically generate an interrupt requests to the local m p / m c repeatedly at one-second intervals. at a minimum, the ?user?s? interrupt service routine must service this interrupt by reading the uni interrupt status register (address = 05h). once the local m p / m c has read this register, then the following things will happen. 1. the ?one-second interrupt? bit-field, within the uni interrupt status register, will be reset to ?0?. 2. the uni will negate the int* (interrupt request) output. the purpose of providing this ?one second? interrupt is to allow the local m p / m c the opportunity to perform certain task at one-second intervals. the user can accomplish this by including the performance of these various tasks as a part of the interrupt service routine, for the ?one-second? type interrupt. some of these tasks could include: ? reading in the contents of the ?one-second? performance monitor registers uni i/o control register (address = 01h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 loc rx loc tx inten reset ami/hdb3* unipolar/bipolar* txline clk inv rxline clk inv reframe ro ro r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 126 ? reading various other performance monitor registers. ? writing a new pmdl message into the ?transmit lapd message? buffer. after the lapd transmitter has been enabled and commanded to initiate transmission of the lapd message frame (containing the pmdl message, residing within the ?transmit lapd message? buffer); the lapd transmitter will continue to re-transmit this same lapd message frame, repeatedly at one-second intervals; until it has been disabled. if the user writes in a new pmdl message, into the lapd transmit buffer, immediately following the occurrence of a ?one-second? interrupt, then he/she can be sure that this ?write activity? will not interfere with thisperiodic transmission of the lapd message. notes regarding the uni interrupt enable and uni interrupt status registers: 1. the uni interrupt enable registers allows the user to globally disable all potential interrupts within a given functional block; by writing a ?0? into the appropriate bit-field of this register. however, the uni interrupt enable register does not allow the user to globally enable all potential interrupts within a given functional block. in other words, enabling a given functional block does not automatically enable all of its potential interrupt sources. those potential interrupt sources that have been disabled at the ?source level? will remain disabled, independent of the status of their associated functional blocks. 2. the uni interrupt enable register is set to 00h upon power up or reset. therefore, the user will have to write some ?1s? to this registers in order to enable some of the interrupts. the remainder of the registers, presented in table 6 will be presented in the discussion of their corresponding functional blocks. these discussions will present more details about the interrupt causes and how to properly service them. 3.7 interfacing the uni to an intel type microprocessor the uni can be interfaced to both ?intel?-type and ?motorola? type microprocessors/microcontrollers. the following sections will provide one example for each type of processor. this section discusses how to interface the XR-T7234 e3 uni to the 8051 microcontroller. the 8051 microcontroller the 8051 family of microcontrollers is manufactured by intel and comes with a variety of amenities. some of these amenities include: ? on chip serial port ? four 8 bit i/o port (p0 - p3) ? two 16 bit timers ? 4k bytes of rom ? 128 bytes of ram
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 127 figure 6 presents a block diagram of the 8051 microcontroller, and figure 7 presents the pin out of this device. figure 6. block diagram of the 8051 microcontroller interrupt control other registers 128 bytes ram (8032/8052) 128 bytes ram rom 0k - 8031/8032 4k - 8051 8k - 8052 timer 2 (8032/8052) timer 1 timer 0 cpu bus control i/o ports serial port rxd* txd* p 0 p 1 p2 p3 serial port timer 0 timer 1 timer 2 (8032/8052) int0* int1* oscillator t2ex* t2* t1* t0* ea* rst ale psen*
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 128 figure 7. pin out of the 8051 microcontroller the 8051 m c consists of 4 8-bit i/o ports. some of these ports have alternate functions as will be discussed below. port 0 (p0.0 - p0.7) this port is a dual-purpose port on pins 32 - 39 of the 8051 ic. in minimal component designs, it is used as a gen- eral purpose i/o port. for larger designs with external memory, it becomes a multiplexed address and data bus (ad0?ad7). port 1 (p1.0 - p1.7) port 1 is a dedicated port on pins 1 - 8. the pins, designated at p1.0, p1.1, p1.2,..., are available for interfacing as required. no alternative functions are assigned for port 1 pins; thus they are used solely for interfacing external devices. exceptions are the 8032/8052 ics, which use p1.0 and p1.1 either as i/o lines or as external inputs to the third timer. port 2 (p2.0 - p2.7) port 2 (pins 21?28) is a dual-purpose port that can function as general purpose i/o, or as the high byte of the address bus for designs with external code memory of more than 256 bytes of external data memory (a8 - 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 p1.0 p1.1 p1.2 p1.3 p1.4 p1.5 p1.6 p1.7 rst p3.0 (rxd) p3.1 (txd) p3.2 (int0*) p3.3 (int1*) p3.4 (t0) p3.5 (t1) p3.6 (wr*) p3.7 (rd*) xtal2 xtal1 vss p2.0 (a8) p2.1 (a9) p2.2 (a10) p2.3 (a11) p2.4 (a12) p2.5 (a13) p2.6 (a14) p2.7 (a15) psen* ale ea* p0.7 (ad7) p0.6 (ad6) p0.5 (ad5) p0.4 (ad4) p0.3 (ad3) p0.2 (ad2) p0.1 (ad1) p0.0 (ad0) vcc 8051 microcontroller
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 129 a15). port 3 port 3 is a dual-purpose port on pins 10 - 17. in addition to functioning as general purpose i/o, these pins have multiple functions. each of these pins have an alternate purpose, as listed in table 8, below. the 8051 also has numerous additional pins which are relevant to interfacing to the XR-T7234 e3 uni or other peripherals. these pins are: ale?address latch enable if port 0 is used in its alternate mode (e.g., as the data bus and the lower byte of the address bus), then ale is the signal that latches the address into an external register during the first half of a memory cycle. once this is done, the port 0 lines are then available for data input or output during the second half of the memory cycle, when the data transfer takes place. int0* (p3.2) and int1* (p3.3) int0* and int1* are external interrupt request inputs to the 8051 m c. each of these interrupt pins support ?direct interrupt? processing. in this case, the term ?direct? means that if one of these inputs are asserted, then program control will automatically branch to a specific (fixed) location in code memory. this location is determined by the cir- cuit design within the 8051 m c ic and cannot be changed. table 9 presents the location (in code memory) where the program control will branch to, if either of these inputs are asserted. therefore, if the user is using either one of these inputs as an interrupt request input, then the user must insure that the appropriate interrupt service routine or unconditional branch instruction (to the interrupt service routine) is located at one of these address locations. table 8. alternate functions of port 3 pins bit name alternate function p3.0 rxd receive data for serial port p3.1 txd transmit data for serial port p3.2 int0* external interrupt 0 p3.3 int1* external interrupt 1 p3.4 t0 timer/counter 0 external input p3.5 t1 timer/counter 1 external input p3.6 wr* external data memory write strobe p3.7 rd* external data memory read strobe table 9. interrupt service routine locations (in code memory) for int0* and int1* interrupt location int0* 0003h int1* 0013h
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 130 if the 8051 m c is required to interface to external components in the data memory space of sizes greater than 256 bytes, then both ports 0 and port 2 must be used as the address and data lines. port 0 will function as a multiplexed address/data bus. during the first half of a memory cycle, port 0 will operate as the lower address byte. during the second half of the memory cycle, port 0 will operate as the bi-directional data bus. port 2 will be used as the upper address byte. ale and the use of a 74hc373 transparent latch device can be used to demultiplex the address and data bus signals. figure 8 presents a schematic illustrating how the XR-T7234 e3 uni can be interfaced to the 8051 m c. figure 8. schematic depicting how to interface the XR-T7234 e3 uni to the 8051 microcontroller the circuitry in figure 8 will function as follows during a uni requested interrupt. the uni device would request an interrupt from the cpu by asserting its ?active-low? int* output pin. this will cause the int0* input pin of the cpu to go ?low?. when this happens the 8051 cpu will finish executing its current instruction, and will then branch pro- 5v a[8:0] d[15:8] d[7:0] ad[7:0] a[15:9] u3 74hc373 d0 3 d1 4 d2 7 d3 8 d4 13 d5 14 d6 17 d7 18 oc 1 g 11 q0 2 q1 5 q2 6 q3 9 q4 12 q5 15 q6 16 q7 19 u1 XR-T7234 txneg 111 txpos 109 txlineclk 112 rxlineclk 99 rxneg 98 rxpos 97 d15 1 d14 3 d13 4 d12 5 d11 9 d10 11 d9 13 d8 14 d7 16 d6 17 d5 18 d4 19 d3 21 d2 23 d1 25 d0 28 a8 37 a7 40 a6 41 a5 42 a4 43 a3 44 a2 45 a1 46 a0 48 txdata15 144 txdata14 142 txdata13 140 txdata12 138 txdata11 134 txdata10 132 txdata9 130 txdata8 128 txdata7 143 txdata6 141 txdata5 139 txdata4 137 txdata3 135 txdata2 133 txdata1 131 txdata0 129 moto/intel 7 rxdata0 70 rxdata1 68 rxdata2 64 rxdata3 62 rxdata4 60 rxdata5 58 rxdata6 56 rxdata7 54 rxdata8 69 rxdata9 67 rxdata10 65 rxdata11 63 rxdata12 61 rxdata13 57 rxdata14 55 rxdata15 53 reset rdy_dtck 160 width16 20 wrb_rw 35 rds_ds 33 ale_as 34 int 29 cs 32 u2 8051 wr 16 rd 17 ad0 39 ad1 38 ad2 37 ad3 36 ad4 35 ad5 34 ad6 33 ad7 32 ale 30 a8 21 a9 22 a10 23 a11 24 a12 25 a13 26 a14 27 a15 28 int0 12 int1 13 to address decoder from address decoder reset command circuitry rxdata[15:0] txdata[15:0]
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 131 gram control the uni interrupt service routine. in the case of figure 8, the interrupt service routine will be located in 0003h in code memory. the 8051 cpu does not issue an interrupt acknowledge signal back to the uni. it will just begin processing through the uni?s interrupt service routine. once the cpu has eliminated the cause(s) of the interrupt request, the uni?s int* pin will be negated (go ?high?) and the cpu will return from the interrupt service routine and resume normal operation. 3.8 interfacing the uni to a motorola type microprocessor this section discusses how to interface the XR-T7234 e3 uni to the 68000 microprocessor. figure 9 presents a schematic on how to interface the XR-T7234 e3 uni to the mc68000 microprocessor, over a 16 bit data bus. figure 9. schematic depicting how to interface the XR-T7234 e3 uni to the mc68000 microprocessor. in general, the approach to interfacing these two devices is pretty straightforward. however, the user must be aware of the fact that the XR-T7234 e3 uni does not provide an interrupt vector to the mc68000, during an ?interrupt acknowledge? cycle. therefore, the user must configure his/her design to support ?auto-vectored? interrupts. ?auto- +5v 5v 5v d[15:0] d[15:0] a[3:1] a[8:0] a[8:0] a[9:1] u1 XR-T7234 txneg 111 txpos 109 txlineclk 112 rxlineclk 99 rxneg 98 rxpos 97 d15 1 d14 3 d13 4 d12 5 d11 9 d10 11 d9 13 d8 14 d7 16 d6 17 d5 18 d4 19 d3 21 d2 23 d1 25 d0 28 a8 37 a7 40 a6 41 a5 42 a4 43 a3 44 a2 45 a1 46 a0 48 txdata15 144 txdata14 142 txdata13 140 txdata12 138 txdata11 134 txdata10 132 txdata9 130 txdata8 128 txdata7 143 txdata6 141 txdata5 139 txdata4 137 txdata3 135 txdata2 133 txdata1 131 txdata0 129 moto/intel 7 rxdata0 70 rxdata1 68 rxdata2 64 rxdata3 62 rxdata4 60 rxdata5 58 rxdata6 56 rxdata7 54 rxdata8 69 rxdata9 67 rxdata10 65 rxdata11 63 rxdata12 61 rxdata13 57 rxdata14 55 rxdata15 53 reset 155 rdy_dtck 160 width16 20 wrb_rw 35 rds_ds 33 ale_as 34 int 29 cs 32 u2 mc68000 reset 18 r/w 9 dtack 10 d0 5 d1 4 d2 3 d3 2 d4 1 d5 64 d6 63 d7 62 d8 61 d9 60 d10 59 d11 58 d12 57 d13 56 d14 55 d15 54 a1 29 a2 30 a3 31 a4 32 a5 33 a6 34 a7 35 a8 36 a9 37 fc0 28 fc1 27 fc2 26 vpa 21 ipl0 25 ipl1 24 ipl2 23 as 6 uds 7 lds 8 a10 38 a11 39 a12 40 a13 41 a14 42 a15 43 a16 44 a17 45 a18 46 a19 47 a20 48 a21 49 a22 50 a23 51 u5 74ahct138 a 1 b 2 c 3 g1 6 g2a 4 g2b 5 y0 15 y1 14 y2 13 y3 12 y4 11 y5 10 y6 9 y7 7 u3 74ahct138 a 1 b 2 c 3 g1 6 g2a 4 g2b 5 y0 15 y1 14 y2 13 y3 12 y4 11 y5 10 y6 9 y7 7 u4 74ahct148 0 10 1 11 2 12 3 13 4 1 5 2 6 3 7 4 ei 5 a0 9 a1 7 a2 6 gs 14 eo 15 u6a 74ahct00 1 2 3 u7a 74ahct04 1 2 u7b 74ahct04 address decoder address decoder rxdata[15:0] txdata[15:0]
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 132 vectored? interrupt processing is a feature offered by the mc68000 family of microprocessors, where, if the micro- processor knows (prior to any iack cycle) the ?interrupt level? of this current interrupt, and that the ?interrupting? peripheral does not support vectored interrupts, then the m p will generate its own interrupt vector. the schematic shown in figure 9, has been configured to support ?auto-vectored? interrupts. functional description of circuit in figure 9 when the XR-T7234 e3 uni generates an interrupt, the int* output will toggle ?low?. this will force input 6, of the ?interrupt priority encoder? chip (u4), to also toggle ?low?. in response to this, the interrupt priority encoder chip will set its three outputs to the following states: a2 = ?0?, a1 = ?0? and a0 = ?1? (which is the number 6 in ?inverted? binary format). the state of three output pins will be read by the ?active-low? interrupt request inputs of the m p (ipl2, ipl1, and ipl0). when the 68000 m p detects this value at its three interrupt request inputs, it will know two things: 1. an interrupt request has been issued by one of the peripheral devices 2. the interrupt request is a ?level 6? interrupt request (due to the values of the a2 - a0 outputs from the ?interrupt priority encoder? ic). once the 68000 m p has determined these two things it will initiate an ?interrupt acknowledge? (iack) cycle by doing the following: 1. identify this new bus cycle as an interrupt service routine by setting all of its function code output pins (fc2?fc0) ?high?. 2. placing the interrupt level on the address bus output pins a[3:1]. when the 68000 m p has toggled all of its function code output pin ?high?, the ?function code decoder? chip (u3) will read this value from the fc2 - fc0 pins as being the binary value for 7. as result, u3 will assert its ?active-low? y7 output pin. at the same time, the address lines a[3:1] are carrying the current ?interrupt level? of this iack cycle (level = 6, or ?1 1 0? in this example) and applying this value to the a, b, and c inputs of the ?iack level decoder? chip (u5). initially, all of the outputs of u5 are ?tri-stated.? due to the fact that its ?active-low? g2a and g2b inputs are negated (e.g., at a logic ?high?). however, when the 68000 m p begins the iack cycle, it will assert its address strobe (as*) signal. this action will result in asserting the g2a input pin of u5. additionally, since the function code decoder chip has also asserted its y7 output pin this will, in turn assert the g2b input pin of u5. at this point, the output of u5 will no longer be ?tri-stated?. u5 will read in the contents of its a, b, and c inputs, and assert the appropriate output pin. in this case, since u5 has the binary value of ?6? applied to its input, it will, in turn assert its ?active-low? y6 output pin. the combination of the intb* output (of the XR-T7234) and y6 (from u5) being asserted will cause u6a to assert the active-low vpa* (valid peripheral address) input pin of the 68000 m p . anytime the 68000 detects its vpa* pin being asserting during an iack cycle, it know that this is an auto-vectored interrupt cycle. when the 68000 is operating in an ?auto-vectored? interrupt cycle, it knows that it will not receive an interrupt vector from the peripheral device (e.g., the XR-T7234 uni in this case), and that it must generate its own vector. in the very next bus cycle, the 68000 m p is going to implement a ?pseudo-read? of the data bus. however, in reality no data will be read from the XR-T7234 device. the 68000 m p will instead have determined that since this current iack is an auto-vectored?level 6 interrupt cycle; which corresponds to vector number 30, within the 68000 m p ?s exception vector table. vector number 30 corresponds to an address space of 78h, in the 68000 m p ?s address space. in the case of this example, the user is required to place an unconditional branch statement (to the location of the XR-T7234 interrupt service routine) at 78h in system level memory. table 10 presents the auto-vector interrupt table (e.g., the relationship between the interrupt level and the corre-
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 133 sponding location in memory for this unconditional branch statement) for the mc68000 m p . table 10. auto-vector interrupt table for the mc68000 microprocessor interrupt level vector number address space 1 25 064h 2 26 068h 3 27 06ch 4 28 070h 5 29 074h 6 30 078h 7 31 07ch
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 134 4.0 the uni test and diagnostic section the ?test and diagnostic? section, within the XR-T7234 e3 uni offers a significant amount of on-chip ?self-test? capability. this ?self-test? capability of the XR-T7234 e3 uni is briefly itemized below. ? the XR-T7234 e3 uni can be configured to operate in one of two loopback modes: line and cell. ? the uni contains an on-chip test cell generator thatis capable of generating test cells with ?user-specified? header byte patterns. the test cell generator also uses an ?on-chip? prbs generator to fill in the bytes for the payload portion of these test cells. ? the ?test and diagnostic? section, within the uni allows the user to route these test cells through the uni, while operating in the ?line-side? test mode. ? the test and diagnostic section includes a test cell receiver that is capable of identifying, terminating, and evaluating the ?post-loopback? test cells. ? the test cell receiver will also report the occurrence of errors, by incrementing an on-chip ?test cell error accumula- tion? register. the uni chip?s test and diagnostic section allows the user to run a wide variety of diagnostic tests, based upon his/her selection of the following three parameters: ? the type of loopback modes ? line side or system side testing ? test cell generator/receiver configuring each of these ?test and diagnostic? parameters are discussed in detail, below. 4.1 the uni chip?s loopback modes the XR-T7234 e3 uni ic allows the user to configure itinto one of two loopback modes: ? line loopback mode ? cell loopback mode the following sections define each of these loopback modes, and discusses how to configure the uni to operate in these modes. 4.1.1 the ?line loopback? mode when the uni is operating in the line loopback mode, the output of the transmit e3 framer (e.g., txpos and txneg) will be internally routed to the input pins of the receive e3 framer (e.g., rxpos and rxneg). figure 10 presents an illustration of the uni chip operating in the line loopback mode.
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 135 figure 10. illustration of the uni operating in the line loopback mode. the user can configure the uni chip to operate in the line loopback mode, by writing the appropriate data to the uni operating mode register (address = 00h), as depicted below. writing a ?1? to bit 2 of the uni operating mode register, configures the uni to operate in the ?line loopback? mode. writing a ?0? to this bit-field disables the line loopback mode. 4.1.2 the cell loopback mode when the uni is configured to operate in the ?cell loopback? mode, then atm cells, that are delineated and pass through the receive cell processor will be routed directly (internally) the tx fifo (within the transmit utopia inter- face block). once these cells arrive at the txfifo, they will be read-in and further processed by the transmit cell processor. these cell will ultimately be routed onto the ?outbound? e3 line via the transmit e3 framer. figure 11, presents an illustration of the uni chip operating in the ?cell loopback? mode. uni operating mode register (address = 00h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 disable loc internal los enable reset by reg. cell loop- back line loopback timrefsel[1, 0] ro r/w r/w r/w r/w r/w r/w r/w uni chip tx ds3 framer rx ds3 framer rx utopia tx cell processor tx utopia tx cell processor line loopback
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 136 figure 11. an illustration of the uni chip operating in ?cell loopback? mode. the user can configure the uni chip to operate in the ?cell loopback? mode, by writing the appropriate data to the uni operating mode register (address = 00h), as depicted below. writing a ?1? to bit 3 of the uni operating mode register, configures the uni to operate in the ?cell loopback? mode. writing a ?0? to this bit-field disables the ?cell loopback? mode. 4.2 line-side/system-side tests the current version of the XR-T7234 e3 uni chip supports ?line-side? testing; but not ?system-side? testing. however, for the sake of completeness, both of these test modes are briefly discussed below. future versions of the uni chip will allow the user to generate test cells and run tests in either the ?line side? mode or in the ?system side? mode. 4.2.1 line-side tests in ?line side? testing, the uni chip will generate some test cells, and will transmit these cells either on or out towards the e3 ?line? (hence the name ?line-side? tests). at some point, these test cells will be looped-back into the receive path, where they will ultimately be terminated, and evaluated by the test cell receiver. these line-side tests are intended to be conducted while the uni is operating in the ?line-loopback? mode (see section 4.1). however, the line side tests can also be conducted while the system (external to the uni device), implements an ?external uni operating mode register (address = 00h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused disable loc internal los enable reset by reg. cell loopback line loopback timrefsel[1, 0] ro r/w r/w r/w r/w r/w r/w r/w uni chip tx ds3 framer rx ds3 framer cell loopback tx utopia rx utopia tx cell processor tx cell processor
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 137 loopback? mode. in this case, no uni loopback mode would be configured, and the user?s system would implement this ?external loopback? by routing the ?transmit e3 line data? (from the uni), back into the rxpos and rxneg inputs of the uni device. note: the cell loopback mode cannot be used in the ?line-side? tests. if the user selects a ?line side? test, then the ?test cell generator? will generate and insert test cells into the txfifo (within the uni). these test cells will be read out of the txfifo by the transmit cell processor, and are ultimately be transmitted out onto the e3 line. eventually (depending upon the type of loopback chosen), these test cells will be routed back into the ?receive path? of the uni device. once in the ?receive path?, those test cells that reach the rxfifo will be identified by their header byte patterns, and collected by the ?test cell receiver? where they will be checked for bit errors. the features and characteristics of the test cell generator and the test cell receiver is discussed in detail in section 4.3. the configuration for the line-side test, while the uni is configured to operate in the line and ?external? loopback modes are illustrated in figures 12 and 13, respectively. figure 12. illustration of line side test, while the uni is configured to operate in ?line loopback? mode. uni chip tx ds3 framer rx ds3 framer line loopback tx utopia rx utopia tx cell processor tx cell processor test cell generator test cell receiver
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 138 figure 13. illustration of line side test, while the uni is configured to operate in the ?external loopback? mode. 4.2.2 ?system-side? testing (not presently supported by the XR-T7234 e3 uni) if the user selects a ?system side? test then the ?test cell generator? will generate and insert the test cells into the rxfifo, where they can be read out and processed by the atm layer processor, via the receive utopia interface block. at some point, these test cells will be looped back into the ?transmit path? (of the uni device), via some externally implemented ?utopia loopback? mode. once in the ?transmit path?, those test cells that reach the txfifo (of the uni) will be identified by their header byte patterns, and collected by the ?test cell receiver? where they will be checked for bit errors. figure 14 presents an illustration of a system side test configuration, while the uni system is operating in a ?utopia loopback mode?, via the atm layer processor. figure 14. illustration of system side test, while the uni system is configure to operating in utopia loopback mode. note: 1. the system-side test is not supported by this version of the XR-T7234 e3 uni ic. 2. the ?utopia loopback? mode, as depicted in figure 14, must be implemented by the user?s system level hardware . uni chip tx ds3 framer rx ds3 framer external loopback tx utopia rx utopia tx cell processor tx cell processor test cell generator test cell receiver liu chip utopia loopback uni chip tx utopia tx ds3 framer rx ds3 framer rx utopia tx cell processor tx cell processor test cell receiver test cell generator atm layer processor
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 139 4.3 operating the test cell generator/ receiver sections 4.1 discussed the various loopback modes that are available within the uni device. section 4.2 discussed line side testing; where the ?internal? test cell generator can be enabled to produce test cells, and write them into the txfifo. these cells will be read out of the txfifo by the transmit cell proces- sor, and routed towards the e3 line. section 4.1 and 4.2 also mentioned that these cells could be ?looped? back into the receive path (of the uni), at various points depending upon the loopback mode selected. when operating the uni in the line side test mode, then the following loopback options are available. ? line loopback ? external loopback (see figure 13) as these test cells proceed through the receive path (after traversing the loopback point), they will eventu- ally arrive at the rxfifo (within the receive utopia interface); where they will be identified, collected and analyzed by the test cell receiver. the next two sections discuss the operation of the test cell generator and the test cell receiver, within the uni test and diagnostic section. 4.3.1 characteristics of the test cell gen- erator the test cell generator has the following characteris- tics: ? it allows the user to specify the header byte pat- terns of these test cells. ? the payload bytes within these test cells will be filled by an internal pseudo-random byte sequence (prbs) pattern generator. ? it allows the user to select one of two ?test cell traffic? generating options. these options are. ? the ?one shot? mode ? the ?continuous? mode ? it generates test cells and writes them into the txfifo (within the transmit utopia interface block); where they will be read from and processed throughout the uni. each of these characteristics of the test cell genera- tor are described in greater detail below. 4.3.1.1 specifying the header byte pat- tern of test cells the user can specify his/her choice for the header byte patterns of these test cells, by writing the ?desired? header byte patterns into the ?test cell header byte? registers 1 through 4 (address = 08h through 0bh); as depicted below. test cell header byte-1 register (address = 08h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 test cell header byte 1 r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0 test cell header byte-2 register (address = 09h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 test cell header byte 2 r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 140 writing the test cell header bytes into these registers accomplishes two things: a. it configures the test cell generator to produce test cells with these header byte patterns; and b. it informs the test cell receiver of the ?header bytes? patterns of these test cells, in order to help it to identify and collect these cells for error-checking purposes. 4.3.1.2 the payload bytes of the test cells the test cell generator will automatically fill the payload portion of these test cells with bytes that are generated by an internal pseudo-random byte sequence (prbs) generator. these prbs generated bytes will ultimately used by the test cell receiver in order to perform error-checking of the ?post-routed? test cells. 4.3.1.3 test cell generator?test cell traffic options the user can configure the test cell generator to generate ?test cells? based upon one of two traffic options: the ?one shot? mode, or the ?continuous? mode. the user can make this selection by writing the appropriate value to bit 2 of the test cell control and status register (address = 06h); as depicted below. test cell header byte-3 register (address = 0ah) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 test cell header byte 3 r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0 test cell header byte-4 register (address = 0bh) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 test cell header byte 4 r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0 test cell control and status register (address = 06h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused test cell enable line/system one shot test one shot done prbs lock
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 141 the user can configure the ?test cell generator? to operate in the ?one shot? mode by writing a ?1? into this bit-field. conversely, the user can configure the ?test cell generator? to operate in the ?continuous? mode by writing a ?0? into this bit-field. 4.3.1.3.1 the ?one shot? mode if the test cell generator is configured to operate in the ?one shot? mode, then upon enabling the test cell gener- ator (by inducing a ?0? to ?1? transition in the ?test cell enable? field of this register), the test cell generator will generate a ?single burst? of 1024 test cells. afterwards, the test cell generator will stop and will not produce any more test cells until the next ?0? to ?1? transition in the ?test cell enable? bit-field. if the test cell generator is operating in the ?one shot? mode, the user can determine its ?progress? in its ?test cell? production by reading bit 1 (one shot done) within the ?test cell control and status register?; as depicted below. if this ?read-only? bit-field contains a ?1? then the test cell generator has completed its generation of the latest burst of 1024 test cells. however, if this bit-field contains a ?0?, then generation of this burst of test cells is still in- process. note: the contents within bit 1 (one shot done) is only relevant if the user is operating the test cell generator in the ?one shot? mode. 4.3.1.3.2 the ?continuous? mode if the test cell generator is configured to operate in the ?continuous? mode, then upon enabling the test cell gen- erator (by writing a ?1? into the ?test cell enable? bit-field in this register), the test cell generator will produce a continuous stream of test cells for the duration that the test cell generator is enabled. 4.3.1.4 enabling the ?test cell generator? the user can enable the ?production? of test cells by writing a ?1? to bit 4 (test cell enable) within the test cell control and status register, as depicted below. r/w r/w r/w r/w r/w r/w ro ro test cell control and status register (address = 06h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused test cell enable line/system one shot test one shot done prbs lock r/w r/w r/w r/w r/w r/w ro ro test cell control and status register (address = 06h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 test cell control and status register (address = 06h)
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 142 writing a ?1? to this bit-field enables the ?test cell generator/receiver?. writing a ?0? disables the ?test cell gener- ator/receiver?. once the test cell generator has been enabled, it will begin to either produce a continuous stream of cells (ifconfigured to operate in the ?continuous? mode), or a single burst of 1024 cells (if configured to operate in the?oneshot? mode.) 4.3.2 characteristics of the test cell receiver the test cell receiver has the following characteristics: ? it checks the header bytes of all cells arriving at the rxfifo (within the receive utopia interface block), in order to determine if they are (or are not) test cells. ? it reads in those cells that have identified as ?test cells? from the rxfifo ? acquires and maintains ?prbs lock? with the payload data, within these test cells. ? reports the occurrences of errors. 4.3.2.1 identifying the test cells the test cell receiver will monitor those cells that reach the rxfifo, within the receive utopia interface block, and , from that ?stream of incoming cells? identify and collect the test cells. the test cell receiver will use the ?user-specified? header byte patterns, as written into the ?test cell header byte? registers - 1 through 4 (address = 08h to 0bh), in order identify these test cells. 4.3.2.2 acquiring and maintaining ?prbs lock? during test cell production, the test cell generator will fill in the ?payload portions? of each test cell with bytes that are generated by a ?pseudo-random byte sequence (prbs) generator. consequently, the data within the cell payload bytes (of these test cells) follows a pre-defined sequence. after the test cell receiver has started to ?collect? these test cells from the rxfifo, it will ?strip off? the cell header bytes and will begin to evaluate their payload bytes. one of the first things that the test cell receiver will try to do is to look for this ?pre-defined (prbs) sequence? within this test cell payload data. once the test cell receiver has found this ?pre-defined? sequence within the test cell payload data, it will inform the user of this fact by asserting the unused test cell enable line/system one shot test one shot done prbs lock r/w r/w r/w r/w r/w r/w ro ro test cell control and status register (address = 06h)
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 143 ?prbs lock? bit-field, within the ?test cell control and status? register; as depicted below. as long as the test cell receiver has found (and continues to find) this pre-defined sequence in the incoming test cell payload data, it will keep this bit-field asserted (e.g., at a logic ?1?). 4.3.2.3 evaluating the test cell payload data and reporting errors once the test cell receiver has acquired ?prbs lock? with the contents of the incoming test cell payload data; then it can begin to compare this data with the ?pre-defined? prbs pattern of data, as produced by the prbs generator (within the test cell generator). if the test cell receiver detects any discrepancies between the test cell payload bytes, and the ?pre-defined? prbs pattern, then it will increment to the ?test cell error accumulator? registers. the ?test cell error accumulator? register actually consists of two 8-bit ?reset upon read? registers, as depicted below. these two register combine to form a 16-bit expression of the number of bit-errors that the test cell receiver has detected within the payload bytes of the ?incoming? test cells. the ?test cell error accumulator?msb? register contains the ?upper? byte value of this 16-bit expression. likewise, the ?test cell error accumulator?lsb? register contains the ?lower? byte value of this 16-bit expression. since these registers are ?reset upon read?, they contain the number of ?test cell payload? bit errors, that have been detected, by the test cell receiver, since the last read of these registers. test cell control and status register (address = 06h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused test cell enable line/system one shot test one shot done prbs lock r/w r/w r/w r/w r/w r/w ro ro 1 0 x x 1 test cell error accumulator?msb (address = 0ch) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 test cell errors?high byte rur rur rur rur rur rur rur rur test cell error accumulator?lsb (address = 0dh) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 test cell errors?low byte rur rur rur rur rur rur rur rur
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 144 5.0 line interface drive and scan section the ?line interface drive and scan? section, of the XR-T7234 e3 uni consists of 5 output pins, three input pins, a ?read/write? register, and a ?read only? register. the purpose of the ?line interface drive and scan? section, is to allow the user to monitor and exercise control over many aspects of the xr-t7295e e3 line receiver ic and the xr-t7296 e3 line transmitter ic; without having to develop the necessary ?off-chip? glue logic. figure 15 presents a circuit schematic that depicts how the XR-T7234 e3 uni should be interfaced to the xr-t7295e / xr-t7296 e3 line interface unit devices. figure 15. circuit schematic illustrating how the XR-T7234 e3 uni should be interfaced to the xr-t7295/xr-t7296 e3 line interface unit devices. as mentioned above, the line interface drive and scan section, consists of five output pins and three input pins. the logic state of the output pins are controlled by the contents within the ?line interface drive? register, as depicted below. line interface drive register (address = 84h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused reqb taos encodis txlev rloop lloop ro ro r/w r/w r/w r/w r/w r/w 5v t1 pe 65966 t2 pe 65966 r1 39 r2 39 r3 39 r4 270 r6 36 r5 270 r7 36 c2 0.01uf c1 0.1uf u2 xr-t7296 ds3, sts-1/e3 4 encodis 11 decodis 12 tndata 8 tpdata 7 tclk 9 rclko 17 rneg 15 rpos 16 rloop 2 taos 5 lloop 3 dmo 18 txlev 25 ttip 23 tring 22 mtip 20 mring 19 rclk 1 rpdata 27 rndata 28 u? XR-T7234 txneg 111 txpos 109 txlineclk 112 rxlineclk 99 rxneg 98 rxpos 97 txaddr0 147 txaddr1 149 txaddr2 150 txaddr3 148 txaddr4 146 txdata15 144 txdata14 142 txdata13 140 txdata12 138 txdata11 134 txdata10 132 txdata9 130 txdata8 128 txdata7 143 txdata6 141 txdata5 139 txdata4 137 txdata3 135 txdata2 133 txdata1 131 txdata0 129 rxdata0 70 rxdata1 68 rxdata2 64 rxdata3 62 rxdata4 60 rxdata5 58 rxdata6 56 rxdata7 54 rxdata8 69 rxdata9 67 rxdata10 65 rxdata11 63 rxdata12 61 rxdata13 57 rxdata14 55 rxdata15 53 rxaddr0 79 txclav 126 txsoc 124 txprty 125 txclk 151 txenb 123 rxclav 76 rxsoc 72 rxprty 74 rxclk 50 rxenb 81 rxaddr1 80 rxaddr2 77 rxaddr3 75 rxaddr4 73 encodis 22 rloop 26 lloop 28 reqb 12 rlos 86 rlol 8 taos 2 txlev 24 dmo 6 u? xr-t7295e rlos 7 rlol 8 lpf1 4 lpf2 5 exclk 13 rndata 12 rpdata 16 rclk 14 rin 2 reqb 18 ttip tring 34.386 mhz rtip rring txdata[15:0] txaddr[4:0] rxaddr[4:0] rxdata[15:0] txsoc txprty 50mhz txenb 50mhz rxenb txclav rxclav rxsoc rxprty
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 145 the role of each of these bit-fields and their corresponding output pins are depicted below. the logic state of the input pins can be monitored by reading the contents of the ?line interface scan? register, as depicted below. 5.1 bit-fields with the line interface drive register bit 5?reqb?(receive equalization bypass control) this ?read/write? bit-field allows the user to control the state of the ?reqb? output pin of the uni device. this output pin is intended to be connected to the ?reqb? input pin of the xr-t7295e e3 line receiver ic. if the user forces this signal to toggle ?high?, then the xr-t7295e device will cause its newly received e3 line signal to ?by-pass? some equalization circuitry within the xr-t7295e device. conversely, if the user forces this signal to toggle ?low?, then the xr-t7295e device will route its newly received e3 line signal through its internal equalization circuitry. writing a ?1? to this bit-field causes the uni device to toggle the ?reqb? output pin ?high?. writing a ?0? to this bit-field causes the uni device to toggle the ?reqb? output pin ?low?. for information on the criteria that should be used when deciding whether to bypass the equalization circuitry or not , please consult the ?xr-t7295e e3 integrated line receiver? data sheet. note: if the customer is not using the xr-t7295e e3 line receiver ic, then he/she can use this bit-field and the ?reqb? output pin for other purposes. bit 4?taos?(transmit all ones signal) this ?read/write? bit-field allows the user to control the state of the ?taos? output pin of the uni device. this output pin is intended to be connected to the ?taos? input pin of the xr-t7296 e3 line transmitter ic. if the user forces this signal to toggle ?high?, then the xr-t7296 device will transmit an ?all ones? pattern onto the line. conversely, if the user commands this output signal to toggle ?low? then the xr-t7296 e3 line transmitter ic will proceed to transmit data based upon the pattern that it receives via the txpos and txneg output pins (of the uni ic). writing a ?1? to this bit-field will cause the ?taos? output pin to toggle ?high?. writing a ?0? to this bit-field will cause this output pin to toggle ?low?. note: if the customer is not using the xr-t7296 e3 line transmitter ic, then he/she can use this bit-field, and the ?taos? output pin for other purposes. bit 3?encodis?(hdb3 encoder disable) this ?read/write? bit-field allows the user to control the state of the ?encodis? output pin of the uni device. this output pin is intended to be connected to the ?encodis? input pin of the xr-t7296 e3 line transmitter ic. if the user forces this signal to toggle ?high?, then the ?internal hdb3 encoder? (within the xr-t7296 device) will be disabled. conversely, if the user commands this output signal to toggle ?low?, then the ?internal hdb3 encoder? (within the xr-t7296 device) will be enabled. writing a ?1? to this bit-field causes the uni ic to toggle the ?encodis? output pin ?high?. writing a ?0? to this bit-field will cause the uni ic to toggle this output pin ?low?. note: 1. the hdb3 encoder, within the xr-t7296 device, is not to be confused with the hdb3 encoding capabilities that exists within the transmit e3 framer block of the uni ic. 2. the user is advised to disabled the hdb3 encoder (within the xr-t7296 ic) if the transmit and receive e3 framers (within the uni) are configured to operate in the hdb3 line code. 3. if the customer is not using the xr-t7296 e3 line transmitter ic, then he/she can use this bit-field and the ?encodis? output pin for other purposes. 0 0 0 0 0 0 0 0 line interface drive register (address = 84h)
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 146 bit 2?txlev ?(transmit level select output) this ?read/write? bit-field allows the user to control the state of the ?txlev? output pin of the uni device. this out- put pin is intended to be connected to the ?txlev? input pin of the xr-t7296 e3 line transmitter ic. if the user commands this signal to toggle ?high?, then the xr-t7296 e3 line transmitter ic will increase the amplitude of its output signal on the line, in order to drive the signal over cable lengths of 225 ft or greater. therefore, the user is recommended to set this output ?high?, if he/she is driving e3 lines signal over 225 ft (or more) of cable. conversely, if the user is driving e3 line signals over less than 225 ft of cable, then he/she is recommended to set this output pin ?low?. writing a ?1? to this bit-field commands the uni to toggle the txlev output ?high?. writing a ?0? to this bit-field com- mands the uni to toggle this output signal ?low?. note: if the customer is not using the xr-t7296 e3 line transmitter ic, then he/she can use this bit-field and the ?txlev? output pin for other purposes. bit 1?rloop?(remote loopback) this ?read/write? bit-field allows the user to control the state of the ?rloop? output pin of the uni device. this out- put pin is intended to be connected to the ?rloop? input pin of the xr-t7296 e3 line transmitter ic. if the user commands this signal to toggle ?high?, then the xr-t7296 e3 line transmitter ic will start operating in the ?remote loopback mode?. conversely, if the user commands this signal to toggle ?low?, then the xr-t7296 device will be operating in the ?normal? mode. writing a ?1? into this bit-field commands the uni to toggle the ?rloop? output signal ?high?. writing a ?0? into this bit-field commands the uni to toggle this output signal ?low?. for a detailed description of the xr-t7296 e3 line transmitter?s operation during ?remote loopback?, please see the ?xr-t7296 ds3/sts-1, e3 integrated line transmitter?s data sheet. note: if the customer is not using the xr-t7296 e3 line transmitter ic, then he/she can use this bit-field and the ?rloop? output pin for other purposes. bit 0 ?lloop this ?read/write? bit-field allows the user to control the state of the ?lloop? output pin of the uni device. this out- put pin is intended to be connected to the ?lloop? input pin of the xr-t7296 e3 line transmitter ic. if the user commands this signal to toggle ?high?, then the xr-t7296 e3 line transmitter ic will start operating in the ?local loopback mode?. conversely, if the user commands this signal to toggle ?low?, then the xr-t7296 device will be operating in the ?normal? mode. writing a ?1? into this bit-field commands the uni to toggle the ?lloop? output signal ?high?. writing a ?0? into this bit-field commands the uni to toggle this output signal ?low?. for a detailed description of the xr-t7296 e3 line transmitter?s operation during ?local loopback?, please see the ?xr-t7296 e3/sts-1, e3 integrated line transmitter?s data sheet. note: if the customer is not using the xr-t7296 e3 line transmitter ic, then he/she can use this bit-field and the ?lloop? output pin for other purposes. 5.2 bit-fields within the line interface scan register address = 85h, line interface scan register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused dmo rlol rlos ro ro ro ro ro ro ro ro
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 147 the meaning/role of each of these bit-field and their corresponding input pins are defined below. bit 2?dmo?(drive monitor output) this ?read-only? bit-field indicates the logic state of the ?dmo? input pin of the uni device. this input pin is intended to be connected to the ?dmo? output pin of the xr-t7296 e3 line transmitter ic. if this bit-field contains a logic ?1?, then the ?dmo? input pin is ?high?. the xr-t7296 e3 line transmitter ic will set this pin ?high? if the drive monitor circuitry (within the xr-t7296 device) has not detected any bipolar signals at the mtip and mring inputs (of the xr-t7296 device) within the last 128 32 bit periods. conversely, if this bit-field contains a logic ?0?, then the ?dmo? input pin is ?high?. the xr-t7296 e3 line transmitter ic will set this pin ?low? if bipolar signals are being detected at the ?mtip? and ?mring? input pins. note: if this customer is not using the xr-t7296 e3 line transmitter ic, then he/she can use this register bit-field and input pin for a variety of other purposes. bit 1?rlol?(receive loss of lock) this ?read-only? bit-field indicates the logic state of the ?rlol? input pin of the uni device. this input pin is intended to be connected to the ?rlol? output pin of the xr-t7295e e3 line receiver ic. if this bit-field contains a logic ?1?, then the rlol input pin is ?high?. the xr-t7295e e3 line receiver ic will set this pin ?high? if the phase-locked- loop circuitry (within the xr-t7295e device) has lost ?lock? with the incoming e3 data-stream and is not properly recovering clock and data. conversely, if this bit-field contains a logic ?0?, then the ?rlol? input pin is ?low?. the xr-t7295e e3 line receiver ic will hold this pin ?low? as long as this ?phase-locked-loop? circuitry (within the xr-t7295e device) is properly ?locked? onto the incoming e3 data-stream, and is properly recovering clock and data from this data-stream. for more information on the operation of the xr-t7295e e3 line receiver ic, please consult the ?xr-t7295 e3 integrated line receiver? data sheet. note: if the customer is not using the xr-t7295e e3 line receiver ic, then he/she can use this bit-field, and the ?rlol? input pin for other purposes. bit 0?rlos?(receive loss of signal) this ?read-only? bit-field indicates the logic state of the ?rlos? input pin of the uni device. this input pin is intended to be connected to the ?rlos? output pin of the xr-t7295e e3 line receiver ic. if this bit-field contains a logic ?1?, then the rlos input pin is ?high?. the xr-t7295e device will toggle this signal ?high? if it (the xr-t7295e e3 line receiver ic) is not detecting a sufficient amount of signal energy on the line, from the incoming e3 data-stream. this event indicates that the xr-t7295e device may be experiencing a loss of signal (los) condition. conversely, if this bit-field contains a logic ?0?, then the ?rlos? input pin is ?low?. the xr-t7295e device will hold this signal ?low? if it is detecting a sufficient amount of signal energy on the line, from the incoming e3 data-stream. for more information on the operation of the xr-t7295e e3 line receiver ic, please consult the ?xr-t7295e e3 integrated line receiver? data sheet. note: asserting the ?rlos? input pin will cause the uni device to declare an los (loss of signal) condition. therefore, the user is advised not to use the ?rlos? input pin as a general-purpose input pin. 0 0 0 0 0 0 0 0 address = 85h, line interface scan register
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 148
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 149 6.0 transmit section the purpose of the transmit section of the XR-T7234 e3 atm uni device is to allow a local atm layer (or atm adaptation layer) processor to transmit atm cell data to a remote piece of equipment via a public or leased e3 transport medium. the transmit section of the e3 uni chip consists of the following blocks: ? transmit utopia interface ? transmit cell processor ? transmit e3 framer the atm layer processor will write atm cell data into the transmit utopia interface block of the uni device. the transmit utopia interface block provides the industry standard atm/phy interface functions. the transmit utopia interface block will ultimately write this cell data to an internal fifo (referred to as tx fifo throughout this document); where it can be read and further processed by the transmit cell processor. the transmit utopia interface block will also perform some parity checking on the data that it receives from the atm layer processor; and will provide signaling to support data-flow control between the atm layer processor and the transmit utopia interface block. the transmit cell processor block will read in the atm cells from the tx fifo. it will then (optionally) proceed to take the first four octets of a given cell and compute the hec (header error check) byte from these bytes. afterwards the transmit cell processor will insert this hec byte into the 5th octet position within the cell. the transmit cell processor will also (optionally) scramble the payload portion of the cell (bytes 6 through 53) in order to prevent user data from mimicking framing or control bits/bytes. once the cell has gone through this process it will then be trans- ferred to the transmit e3 framer. if the tx fifo (within the transmit utopia interface block) is depleted and has no (user) cells available, then the transmit cell processor will automatically generate, process and transmit idle cells, in the exact same manner as with user cells. this generation and transmission of idle cells is also known as cell- rate decoupling (e.g., idle cells are generated in order to fill up the bandwidth of the pmd carrier requirements? 34.368 mbps in this case). the transmit cell processor has provisions to allow the user to generate and transmit an oam cell via software control. note: the oam cells will be subjected to the same processing as are user and idle cells (e.g., hec byte calculation and insertion, cell payload scrambling). the transmit e3 framer will take the atm cells that it has received from the transmit cell processor, and insert this data into the payload portions of the e3 frame. the transmit e3 framer will also generate and insert overhead bytes that support framing, performance monitoring (parity bits), path maintenance data link as well as alarm and status information originating from the (near-end) receiver section of this uni. the purpose of these alarm and status information bits is to alert the far-end equipment that the (near end) uni receiver has detected some prob- lems in receiving data from it. the transmit e3 framer supports the itu-t g.832 framing format. the following sections discuss the blocks comprising the transmitter portion of the e3 uni in detail. 6.1 transmit utopia interface block 6.1.1 brief description of the transmit utopia interface the transmit utopia interface block provides a ?utopia level 2? compliant interface that allows the atm layer or atm adaptation layer processors to interconnect to the uni device. the atm layer processor will write atm cell data into the uni via the transmit utopia interface block. the transmit utopia interface block is capable or receiv- ing atm cell data at data rates of up to 800 mbps. this interface will support both an 8 and 16 bit wide data bus. since the atm layer processor writes atm cell data into the transmit utopia interface block at clock rates indepen- dent of the line bit rate (in this case, e3), the received data (from the atm layer processor) is written into an internal fifo. this fifo will be referred to as the tx fifo throughout this document. the contents of the tx fifo will be read-in and further processed by the transmit cell processor. data-flow control between the atm layer processor
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 150 and the transmit utopia interface block is provided by the txclav pin. figure 16 presents a simple illustration of the transmit utopia interface block and the associated pins. figure 16. simple block diagram of transmit utopia interface 6.1.2 functional description of the transmit utopia interface the purposes of the transmit utopia interface block are to: ? receive atm cell data from the aal or atm layer processor. ? make these cells available to the transmit cell processor block. ? provide some form of flow control of cell data from the atm layer processor (via the txclav output pin). ? check the parity of the data received from the atm layer processor, with an option to discard errored cells. ? detect and discard ?runt? cells, and resume normal operation afterwards. the transmit utopia interface block consists of the following sub-blocks. ? transmit utopia input interface ? transmit utopia configuration/status registers ? transmit utopia fifo manager ? transmit utopia cell fifo (tx fifo) the transmit utopia interface block consists of an input interface which complies to the ?utopia level 2 interface specifications?, and the tx fifo. the width of the transmit utopia data bus is user-configurable to 8 or 16 bits. the incoming data bytes or words (16 bits) are checked for odd-parity. the computed parity bit is then compared with that presented at the txprty input pin, while the corresponding data byte [word] is present at the txdata[15:0] input. interrupts are generated upon error conditions. cells with parity error may be dropped if enabled through a register setting. the transmit utopia interface block can be configured to process 52, 53, or 54 bytes per cell. if the transmit utopia interface block detects a ?runt? cell (e.g., a cell that is smaller than what the transmit utopia interface block has been configured to handle), it will generate an interrupt to the local m p , discard this ?runt? cell, and resume normal operation. the physical depth of the txfifo is sixteen cells with the operating fifo depth user-configurable to four, eight, twelve or sixteen cells by register settings. the incoming data (from the atm layer processor) is written into the tx fifo where it can be read-in and further processed by the transmit cell processor. a fifo manager maintains the to transmit cell processor txclk txdata[15:0] txprty txsoc txenb* txclav/tfullb* txaddr[4:0] transmit utopia interface
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 151 tx fifo and indicates fifo empty, fifo full, cell space available, etc. figure 17 presents a functional block diagram of the transmit utopia interface block. figure 17. functional block diagram of the transmit utopia block the following sections discuss each functional sub-block of the transmit utopia interface block in detail. these sections will discuss the many features associated with the transmit utopia interface block as well as how the user can select/configure these features in order to suit his/her application needs. detailed discussions of single-phy and multi-phy operation will each be presented in their own section even though it involves the use of all of these functional blocks. 6.1.2.1 transmit utopia bus input interface the transmit utopia input interface complies with utopia level 2 standard interface (e.g., the transmit utopia can support both single-phy and multi-phy operations.) additionally, the uni provides the user with the option of varying the following features associated with the transmit utopia bus interface. ? transmit utopia data bus width of 8 or 16 bits ? the cell size (e.g., the number of octets being processed per cell via the utopia bus) ? the handling of errored cells received from the atm layer processor a discussion of the operation of the transmit utopia bus interface along with each of these options will be pre- sented below. 6.1.2.1.1 the pins of the transmit utopia bus interface the atm layer processor will interface to the transmit utopia interface block via the following pins. ? txdata[15:0]?transmit utopia data bus input pins tx utopia fifo manager tx utopia cell fifo txdata[15:0] txdata[7:0] txaddr[4:0] txenb txsoc txclk txutopia interrupt status bits to registers txclav/txfullb txcel present txfdat[7:0] tusoc controls from registers txfrdclk trdenb (to tx cell processor) (to pin) (to interrupt block) to tx cell processor from tx cell processor txutopia registers d[15:0] a[8:0] status signals control signals up interface
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 152 ? txaddr[4:0]?transmit utopia address bus input pins ? txclk?transmit utopia interface block clock input pin ? txsoc?transmit ?start of cell? indicator input pin ? txprty?transmit utopia?odd parity input pin ? txenb*?transmit utopia data bus?write enable input pin ? txclav/tfullb*?txfifo cell available each of these signals are briefly discussed below. txdata[15:0] ?transmit utopia data bus input pins the atm layer processor will write its atm cell data into the transmit utopia interface block, by placing it, in a byte-wide (or word-wide) manner on these input pins. the transmit utopia data bus can be configured to operate in the ?8-bit wide? or ?16-bit wide? modes (see section 6.1.2.1.2). if the ?8-bit wide? mode is selected, then only the txdata[7:0] input pins are active and capable of receiving data. if the ?16-bit wide? mode is selected, the all 16 input pins (e.g., txdata[15:0]) are active. the transmit utopia data bus is tri-stated while the active-low txenb* (transmit utopia data bus? write enable) input signal is ?high?. therefore, the atm layer processor must assert this signal (e.g., toggling txenb* ?low?) in order write the cell data, on the transmit utopia data bus, into the transmit utopia interface block. the data on the transmit utopia data bus is sampled and latched into the transmit utopia inter- face block, on the rising edge of the transmit utopia interface block clock signal, txclk. additionally, the transmit utopia interface block will only process one cell worth of data (e.g., 52, 53 or 54 bytes, asconfigured via the cellof52bytes option?see section 6.1.2.1.3), following the latest assertion of the txsoc (transmit-start of cell) pin. afterwards, the transmit utopia data bus will become tri-stated and will cease to process any more data from the atm layer processor until the next assertion of the txsoc pin. once the transmit utopia interface block reaches this condition, it will ignore the assertions of the txenb* pin, and will keep the transmit utopia data bus input pins tri-stated until the atm layer processor pulses the txsoc input pin, once again. if the transmit utopia interface block detects a ?runt? cell (e.g., if the amount of data that is read into the txfifo is less than that configured via the ?cellof52bytes? option), then the transmit utopia interface block will discard this cell, and resume normal operation. note: the 100 pin version of the XR-T7234 device allocates only 8 pins for the transmit utopia data bus: txdata[7:0]. the transmit utopia data bus pins: txdata[15:8] are not available. txaddr[4:0]?transmit utopia address bus input pins these input pins are used only when the uni is operating in the multi-phy mode. therefore, for more information on the transmit utopia address bus, please see section 6.1.2.3.2. txclk?transmit utopia interface block clock signal input pin the transmit utopia interface block uses this signal to sample and latch the data on the transmit utopia data bus and the transmit utopia address bus (for multi-phy operation) into the transmit utopia interface block. this clock signal can run at frequencies of 25 mhz, 33 mhz, or 50 mhz. txenb*?transmit utopia data bus?write enable input pin the transmit utopia data bus is tri-stated while this input signal is negated. therefore, the atm layer processor must assert this ?active-low? signal (toggle it ?low?) in order to write the byte (or word) on the transmit utopia data bus, into the transmit utopia interface block. txprty?transmit utopia?odd parity bit input pin the atm layer processor is expected to compute the odd-parity value of each byte (or word) of atm cell data that it intends to place on the transmit utopia data bus. the atm layer processor is then expected to apply this parity value at the txprty pin, while the corresponding byte (or word) is present on the transmit utopia data bus.
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 153 txsoc?transmit utopia??start of cell? indicator input pin the atm layer processor is expected to pulse this signal ?high?, for one clock period of txclk, when the first byte (or word) of a new cell is present on the transmit utopia data bus. this signal must be kept ?low? at all other times. note: once the atm layer processor has pulsed the txsoc pin ?high?, the transmit utopia interface block will pro- ceed to read in and process only one cell of data (e.g., 52, 53, or 54 bytes, as configured via the ?cellof52bytes? option?see section 6.1.2.1.3) via the transmit utopia data bus. afterwards, the transmit utopia interface block will cease to process any more data from the atm layer processor until the txsoc pin has been pulsed ?high? once again. this phenomenon is more clearly defined in ?example?1? below. further, if the atm layer processor pulses the txsoc pin, before the appropriate number of bytes (as configured via the ?cellof52bytes? option?see section 6.1.2.1.3), have been read in and processed by the transmit utopia interface block, then a ?runt? cell will have been detected. whenever the transmit utopia interface block detects a ?runt? cell, it will generate a ?change in cell alignment? interrupt and will discard the ?runt? cell. this phenomenon is more clearly defined in ?example?2? below. example-1 for example, if the user configures the transmit utopia interface block to process 53 bytes per cell; then following the assertion of the txsoc pin (which is coincident with the placement of the first byte of the cell on the transmit utopia data bus), the transmit utopia interface block will read in and process 52 more bytes of data via the transmit utopia data bus; resulting in a total of 53 bytes being processed. after the transmit utopia interface block has read in the 53rd byte, it will no longer read in any more data from the atm layer processor, until the txsoc pin has been asserted. example?2 if the atm layer processor were to prematurely assert the txsoc pin, (e.g., when the 52nd byte is present on the transmit utopia data bus, then the transmit utopia interface block will interpret the previous 52 bytes of cell data as a ?runt? cell. the transmit utopia interface block will then generate a ?change of cell alignment? interrupt and will proceed to discard this runt cell. txclav/tfullb?tx fifo cell available/txfifo full* this output signal is used to provide some data flow control between the atm layer processor and the transmit utopia interface block. please see section 6.1.2.2.1 for more information regarding this signal. 6.1.2.1.2 selecting the utopia data bus width (applies to the 160 pin version only) the utopia data bus width can be selected to be either 8 or 16 bits by writing the appropriate data to the utopia configuration register, as shown below. if the user chooses a utopia data bus width of 8 bits, then only the transmit utopia data input pins: txdata[7:0] will be active. (the input pins: txdata[15:8] will not be active). if the user chooses a utopia data bus width of 16 bits, then all of the transmit utopia data input pins: txdata[15:0] will be active. the following table relates the value of utopia configuration register (address = 7ch) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused handshake mode m-phy cellof52 bytes txfifodepth[1, 0] utwidth16 ro r/w r/w r/w r/w r/w
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 154 bit 0 (utwidth) within the utopia configuration register, to the corresponding width of the utopia data bus. note: 1. the selection of this bit-field also effects the width of the receive utopia data bus. 2. upon power up or reset, the utopia data bus width will be 8 bits. therefore, the user must write a ?1? to this bit in order to set the width of the transmit utopia (and the receive utopia) data buses to 16 bits. 3. this option is only available for the 160 pin packaged version of the XR-T7234 device. the 100 pin device only contains transmit utopia data bus input pins; txdata[7:0]. txdata[15:8] are not available in the 100 pin version. 6.1.2.1.3 selecting the cell size (number of octets per cell) the uni allows the user with to select the number of octets per cell that the transmit utopia interface block will process, following each assertion of the txsoc input pin. specifically, the user has the following cell size options. ? if the utopia data bus width is set to 8 bits then the user can choose: ? 52 bytes (with no hec byte in the cell), or ? 53 bytes (with either a dummy or actual hec byte in the cell) ? if the utopia data bus width is set to 16 bits then the user can choose: ? 52 bytes (with no hec byte in the cell), or ? 54 bytes (with either a dummy or actual hec byte, and a stuff byte in the cell) the user makes his/her selection by writing the appropriate data to bit 3 (cellof52 bytes) within the utopia configuration register, as depicted below. the following table specifies the relationship between the value of this bit and the number of octets/cell that the transmit utopia interface block will process. note: this selection applies to both the transmit utopia and receive utopia interface blocks. additionally, the shaded table 11. the relationship between the contents of bit field 0 (utwidth16) within the utopia configuration register and the operating width of the utopia data bus value for utwidth16 width of utopia data bus 0 8 bit wide data bus 1 16 bit wide data bus utopia configuration register (address = 7ch) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused handshake mode m-phy cellof52 bytes txfifodepth[1, 0] utwidth16 ro r/w r/w r/w r/w r/w table 12. the relationship between the contents of bit 3 (cellof52bytes) within the utopia configuration register, and the number of octets per cell that will be processed by the transmit and receive utopia interface blocks cellof52 bytes number of bytes/cells 0 53 bytes when the utopia data bus width is 8 bits. 54 bytes when the utopia data bus width is 16 bits. 1 52 bytes, regardless of the configured width of the utopia data bus
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 155 selection reflects the default condition upon power up or reset. 6.1.2.1.4 parity checking and handling of atm cell data received from the atm layer processor the atm layer processor is expected to compute the odd parity bit for all bytes or words that it intends to write into the transmit utopia interface block. the atm layer processor is then expected to apply the value of this parity bit to the txprty input pin of the uni, while the corresponding byte (or word) is present on the transmit utopia data bus. the transmit utopia interface block will independently compute the odd parity of the contents on the transmit utopia data bus. afterwards, the transmit utopia interface block will compare its calculated value for parity with that placed on the txprty input pin (by the atm layer processor). if these two values are equal, then the byte (or word) of data will be processed through the transmit utopia interface block. however, if these two parity values are not equal, then the ?detection of parity error (transmit utopia interface)? interrupt will occur, and the cell comprising this errored byte (or word) will be (optionally) discarded. the user can configure the transmit utopia interface block to discard or retain this ?errored? cell by writing the appropriate data to the transmit utopia interrupt/status register (address = 80h) as depicted below. if the user sets this bit-field to a ?1?, then the transmit utopia input interface block will discard the errored cell. if the user sets this bit-field to ?0?, then the transmit utopia interface block will not discard the errored cell; and this cell will be written into the tx fifo. 6.1.2.2 transmit utopia fifo manager the tx fifo manager has the following responsibilities. ? monitoring the fill level of the tx fifo, and providing the appropriate level of flow control of data between the transmit utopia interface block and the atm layer processor. ? detecting and discarding ?runt? cells and insuring that the tx fifo can resume normal operation following the removal of the runt cell. ? insuring that the tx fifo can respond properly to an ?overrun? condition, by generating the ?tx fifo overrun condition? interrupt, discarding the resulting ?runt? or errored cell, and resuming proper operation afterwards. transmit utopia fifo manager features and options this section discusses the numerous features that are provided by the transmit utopia fifo manager. additionally, this section discusses how the user can customize these features to suit his/her application needs. the transmit utopia fifo manager provides the user with the following options. ? handshaking mode (octet level vs cell level) ? user selected operating tx fifo depth ? resetting the tx fifo ? monitoring the tx fifo 6.1.2.2.1 selecting the handshaking mode (octet level vs cell level) the transmit utopia interface block offers two different data flow control modes for data transmission between the atm layer processor and the uni ic. these two modes are: ?octet-level? handshaking and ?cell-level? handshaking; tx ut interrupt/status register (address = 80h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 txfifo reset discard upon perr tperr inten txfifo errinten tcoca inten tperr intstat txfifo overint stat tcoca intstat r/w r/w r/w r/w r/w rur rur rur
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 156 as specified by the utopia level 2, version 8 specifications, and are discussed below. 6.1.2.2.1.1 octet-level handshaking the uni will be operating in the ?cell-level? handshaking mode following power up or reset. therefore, the user have to set bit 5 (handshaking mode) of the utopia configuration register to ?0? in order to configure the uni into the ?octet-level? handshake mode. the main signal that is responsible for data flow control, between the atm layer processor and the transmit utopia interface block is the txclav output pin. the atm layer processor is expected to monitor the txclav output pin in order to determine if it is ok to write data into the tx fifo. the txclav output pins exhibits a role that is similar to cts (clear to send) in rs-232 based data transmission systems. as long as txclav is at a logic ?high?, the atm layer processor is permitted to write more cell data bytes (or words) into the transmit utopia interface block (and in turn, the txfifo). however, when the txclav pin toggles ?low?, this indicates that the tx fifo can only accept 4 (or less) more write operations from the atm layer processor. once the txclav pin returns high, this indicates that the txfifo can accept more than 4 write operations from the atm layer processor, and that the atm layer processor can resume writing data to the transmit utopia interface block. in other words, if the utopia data bus is configured to be 8-bits wide, then the txclav signal will toggle ?low? when the txfifo can only accept 4 (or less) bytes of atm cell data, from the atm layer processor. if the utopia data bus is configured to be 16-bits wide; then the txclav signal will toggle ?low? when the txfifo can only accept 8 (or less) bytes of atm cell data from the atm layer processor. figure 18 presents a timing diagram illustrating the behavior of txclav during writes to the transmit utopia inter- face block, while operating in the octet-level handshaking mode. figure 18. timing diagram of txclav and various other signals during writes to the transmit utopia interface block, while operating in the octet-level handshaking mode. notes regarding figure 18: 1. the transmit utopia data bus is configured to be 16 bits wide. hence, the data which the atm layer processor places on the transmit utopia data bus is expressed in terms of 16-bit words: (e.g., w0?w26.) 2. the transmit utopia interface block is configured to handle 54 bytes/cell. hence, figure 18 illustrates the atm layer processor writing 27 words (w0 through w26) for each atm cell. in figure 18, txclav is initially ?high? during clock edge # 1. however, shortly after the atm layer processor writes in word w20, txclav toggles ?low?, indicating that the txfifo is starting to fill up. the atm layer processor will detect this ?negation of txclav? during clock edge #2; while it is writing word w21 into the transmit utopia interface block. at this point, the atm layer processor is only permitted to execute four more ?write? operations with the transmit utopia interface block. therefore, the atm layer processor will proceed to write in words: w22, w23, txclk txclav txenb* txdata[15:0] txsoc x x x w26 w0 w1 w25 w24 w23 w22 w21 w20 1 2 3 4 5 6 7 8 9 10 11 12
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 157 w24 and w25 before negating txenb*. the atm layer processor must keep txenb* negated until it detects that txclav has once again returned ?high?. in figure 20, txclav is asserted after clock edge #8. the atm layer pro- cessor detects this transition in txclav at clock edge #9; and subsequently, asserts txenb*. the atm layer resumes writing in more atm cell data into the transmit utopia interface block. 6.1.2.2.1.2 cell-level handshaking the uni will be operating in the ?cell-level? handshaking mode following power up or reset. in the ?cell-level? handshaking mode, when the txclav is at a logic ?1?, it means that the tx fifo has enough remaining empty space for it to receive at least one more full cell of data from the atm layer processor. however, when txclav toggles from ?high? to ?low?, it indicates that the very next cell (following the one that is currently being written) cannot be accepted by the tx fifo. conversely, once txclav has returned to the logic ?1? level, it indicates that at least one more full cell may be written into the tx fifo by the atm layer processor. as in the ?octet-level? handshake mode, the atm layer processor is expected to poll the txclav output pin towards the end of transmission of the cell currently being written and to proceed with transmission of the next cell only if txclav is at a logic ?high?. the uni can operate in either the ?octet-level? or the ?cell-level? handshake mode, when operating in the single-phy mode. however, only the ?cell-level? handshake mode is available when the uni is operating in the multi-phy mode. for more information on single phy and multi phy operation, please see section 6.1.2.3. the user can configure the uni to operate in one of these two handshake modes by writing the appropriate data to bit 5 (handshake mode) within the utopia configuration register, as depicted below. the following table specifies the relationship between this bit and the corresponding handshaking mode. note: 1. the handshaking mode selection applies to both the transmit utopia interface and receive utopia interface blocks. 2. since multi-phy mode operation requires the use of ?cell-level? handshaking; this bit-field is ignored if the uni is operating in the multi-phy mode. 3. finally, the uni will be operating in the ?cell-level? handshaking mode upon power up or reset. therefore, the user must write a ?0? to this bit-field in order to configure the uni into the ?octet level handshaking? mode. figure 19 presents a timing diagram that illustrates the behavior of various transmit utopia interface block signals, utopia configuration register (address = 7ch) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused handshake mode m-phy cellof52 bytes txfifodepth[1, 0] utwidth16 ro r/w r/w r/w r/w r/w table 13. the relationship between the contents in bit field 5 (handshake mode) within the utopia configuration register and the resulting utopia interface handshake mode. value utopia interface handshake mode 0 the utopia interfaces operate in the ?octet level? handshake mode. 1 the utopia interfaces operate in the ?cell level? handshake mode.
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 158 when the transmit utopia interface block is operating in the ?cell-level? handshaking mode. figure 19. timing diagram of various transmit utopia interface block signals, when the transmit utopia interface block is operating in the ?cell level handshaking? mode. notes regarding figure 19: 1. the transmit utopia data bus is configured to be 16 bits wide. hence, the data, which the atm layer processor places on the transmit utopia data bus, is expressed in terms of 16-bit words: w0?w26. 2. the transmit utopia interface block is configured to handle 54 bytes/cell. hence, figure 19 illustrates the atm layer processor writing 27 words (w0 through w26) for each atm cell. in figure 19, the atm layer processor starts to write in a new atm cell, into the transmit utopia interface block, during clock edge #2. however, shortly after the atm layer processor has written in word w22, txclav toggles ?low?. in the ?cell-level? handshaking mode, this means that atm layer processor is not permitted to write in the subsequent cell (e.g., the cell which is to follow the one that is currently being written into the transmit utopia inter- face block). hence, the atm layer processor must complete writing in the current cell, and then halt with any fur- ther write operations to the transmit utopia interface block. therefore, the atm layer processor proceeds to write in words w23 through w26 and then negates the txenb* signal after clock edge #28. at this point, the atm layer processor must wait until txclav toggle ?high? once again; before writing in the next atm cell. 6.1.2.2.2 selecting the operating depth of the tx fifo the physical depth of the tx fifo is 16 cells. however, for various reasons the user may wish to operate with a smaller fifo depth. therefore, the uni allows the user to select an operating depth of 4, 8, 12 or the full 16 cells. the user can make this selection by writing the appropriate data to bits 1 and 2 (txfifodepth[1, 0]) within the utopia configuration register, as depicted below. the following table presents the values for both bits 1 and 2 (within the utopia configuration register) and the utopia configuration register: address = 7ch bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused handshake mode m-phy cellof52 bytes txfifodepth[1, 0] utwidth16 ro r/w r/w r/w r/w r/w txclk txclav txenb* txdata[15:0] txsoc w26 w0 w1 w2 w23 w24 w25 w26 w22 x x 1 2 3 4 24 25 26 27 28 29 30
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 159 corresponding operating depth of the txfifo. the operating depth of the transmit fifo will be 16 cells upon power up or reset. therefore, the user must write the appropriate data to these two bit-fields in order to change this parameter. 6.1.2.2.3 resetting the tx fifo via software command the uni allows the user to reset the tx fifo, via software command, without the need to implement a master reset of the entire uni device. this can be accomplished by writing the appropriate data to bit 7 (txfifo reset) within the transmit utopia interrupt enable/status register as depicted below. 6.1.2.2.5 monitoring the tx fifo status the local m p has the ability to poll and monitor the status of the tx fifo via the transmit utopia fifo status register (address = 71h). the bit format of this register is presented below. the following tables define the values for bits 1 and 0 and their corresponding meaning. table 14. the relationship between txfifodepth[1:0] within the utopia configuration register and the operating depth of the txfifo bit 2 bit 1 operating depth of the transmit fifo 0 0 16 cells 0 1 12 cells 1 0 8 cells 1 1 4 cells tx ut interrupt/status register (address = 80h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 txfifo reset discard upon perr tperr inten txfifo errinten tcoca inten tperr intstat txfifo overint stat tcoca intstat r/w r/w r/w r/w r/w rur rur rur tx ut fifo status register (address = 71h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused txfifo full txfifo empty ro ro ro ro ro ro ro ro txfifo full txfifo full (bit 1) meaning 0 tx fifo is full, the atm layer processor risks causing an overrun if it writes to the txfifo now. 1 tx fifo is not full.
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 160 6.1.2.3 utopia modes of operation (single phy and multi-phy operation) the uni chip can support both single-phy and multi-phy operation. each of these operating modes are dis- cussed below. 6.1.2.3.1 single phy operation the uni chip will be operating in the multi-phy mode upon power up or reset. therefore, the user must write a ?1? to bit 4 within the utopia configuration register (address = 7ch) in order to configure the uni into the ?single-phy? mode. writing a ?1? to this bit-field configures the uni to operate in the single-phy mode. writing a ?0? configures the uni to operate in the multi-phy mode. in single-phy operation, the atm layer processor is pumping data into and receiving data from only one uni txfifo empty txfifo empty (bit 0) meaning 0 tx fifo is not empty 1 tx fifo is empty. the tx cell processor is currently generating idle cells utopia configuration register (address = 7ch) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused handshake mode s-phy/m- phy* cellof52 bytes txfifodepth[1, 0] utwidth16 ro r/w r/w r/w r/w r/w
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 161 device, as depicted below in figure 20. figure 20. simple illustration of single-phy operation this section presents a detailed description of the transmit utopia interface block operating in the ?single-phy? mode. a description of the receive utopia interface block operating in the ?single-phy? mode is presented in section 7.3.2.2.2.1. whenever the atm layer processor wishes to write one or a series of atm cells to the transmit utopia interface block, it must do the following. 1. check the level of the txclav output pin. if the txclav pin is ?high? then there is available space in the tx fifo for more atm cell data and the atm layer processor may begin writing cell data to the transmit utopia interface block. however, if the txclav pin is ?low?, then the tx fifo is too full to accept anymore data and the atm layer processor must wait until txclav toggles ?high? before writing any cell data to the transmit utopia interface block. note: the actual meaning of txclav toggling ?low? depends upon whether the uni is operating in the ?cell level? or ?octet level? handshake modes. 2. apply the first byte (or word) of the new cell to the transmit utopia data bus. the atm layer processor must designate this byte (or word) as the beginning of a new cell, by pulsing the txsoc pin ?high? for one clock period of txclk. 3. apply the odd-parity value of this first byte (or word), currently residing on the transmit utopia data bus, to the txprty input pin. this should be done concurrently with pulsing the txsoc input pin ?high?. 4. assert the ?transmit utopia data bus??write enable signal, txenb*. this step should also be done concurrently with pulsing the txsoc input pin ?high?. when writing the subsequent bytes (word) of the cell, the atm layer processor must repeatedly exercise steps 3 and 4, of the above list. if the uni is operating in the octet-level handshake mode, then the atm layer processor should check the level of e3 uni atm switch (atm layer device) txdata[15:0] rxdata[15:0] txclav txpos txneg rxpos rxneg txflow control input to/from e3 liu rxclav txsoc txenb* txprty txclk rxclk rxsoc rxenb* rxprty rxflow control input rx start of cell input tx start of cell output txlineclk rxlineclk rx read output enable signal tx write enable output rx utopia data bus parity tx utopia data bus parity rx fifo clock signal tx fifo clock signal rx atm cell data tx atm cell data
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 162 the txclav signal, at least once for every four (4) writes of atm cell data to the transmit utopia interface block. if the uni is operating in the cell-level handshake mode, then the atm layer processor should check the level of the txclav signal, as it nears completion of writing in a given cell. the above-mentioned procedure is also depicted in flow-chart form in figure 21; and in timing diagram form in figures 22 and 23. figure 21. flow chart depicting the approach that the atm layer processor should take when writing atm cell data into the transmit utopia interface block, when the uni is operating in the single phy mode. figure 22. timing diagram of atm layer processor transmitting data to the uni over the utopia data bus, (single-phymode/cell-level handshaking). start check the level of the txclav pin. is txclav ?high?? is this the first byte (word) of a new cell? is the current cell complete? is there anymore cells to write ? end assert the txsoc input pin. place the first byte (word) on the transmit utopia data bus. place the odd-parity value of this byte (word) on the txprty input pin. assert the ?transmit utopia data bus write enable? pin, txenb*. perform the following, concurrently writing the first byte/word of a cell perform the following, concurrently place the next byte (word) on the transmit utopia data bus. place the odd-parity value of this byte (word) on the txprty input pin. assert the ?transmit utopia data bus write enable? pin, txenb*. writing the remaining bytes/ words of a cell no yes yes no no no yes yes txclk txclav txenb* txdata[15:0] txsoc w26 w0 w1 w2 w23 w24 w25 w26 w22 x x 1 2 3 4 24 25 26 27 28 29 30
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 163 notes regarding figure 22: 1. the transmit utopia data bus is configured to be 16 bits wide. hence, the data, which the atm layer proces- sor places on the transmit utopia data bus, is expressed in terms of 16-bit words: w0 - w26. 2. the transmit utopia interface block is configured to handle 54 bytes/cell. hence, figure 22 illustrates the atm layer processor writing 27 words (w0 through w26) for each atm cell. 3. the transmit utopia interface block is configured to operate in the cell-level handshaking mode. figure 23. timing diagram of atm layer processor transmitting data to the uni over the utopia data bus (single-phymode/octet-level handshaking). notes regarding figure 23: 1. the transmit utopia data bus is configured to be 16 bits wide. hence, the data, which the atm layer processor places on the transmit utopia data bus, is expressed in terms of 16-bit words: w0?w26. 2. the transmit utopia interface block is configured to handle 54 bytes/cell. hence, figure 23 illustrates the atm layer processor writing 27 words (w0 through w26) for each atm cell. 3. the transmit utopia interface block is configured to operate in the octet-level handshaking mode. final comments on single-phy operation the important thing to note about the single-phy mode is that the txclav pin is used as a data flow control pin, and has a role somewhat similar to rts (request to send) in rs-232 based data transmission. the txclav pin will have a slightly different role when the uni is operating in the multi-phy mode. the uni, while operating in single phy mode, can be configured for either ?octet-level? or ?cell level? handshaking. in either case, the atm layer processor is expected to poll the txclav output pin before writing the next byte, word or cell to the txfifo. 6.1.2.3.2 multi phy operation the uni ic will be operating in the ?multi-phy? mode upon power up or reset. in the ?multi-phy? operating mode, the atm layer processor may be writing data into and reading data from several uni devices in parallel. when the uni is operating in the multi-phy mode, the transmit utopia interface block will support two kinds of operations with the atm layer processor: ? polling for ?available? uni devices. ? selecting which uni (out of several possible uni devices) to write atm cell data to. each of these operations are discussed in the sections below. however, prior to discussing each of these operations, txclk txclav txenb* txdata[15:0] txsoc x x x w26 w0 w1 w25 w24 w23 w22 w21 w20 2 3 4 5 6 7 8 9 10 11 12 1
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 164 the reader must understand the following. ?multi-phy? operation involves the use of one (1) atm layer processor and several uni devices, within a system. the atm layer processor is expected to read/write atm cell data from/to these uni devices. hence, ?multi-phy? operation requires, at a minimum, some means for the atm layer processor to uniquely identify a uni device (within the ?multi-phy? system) that it wishes to ?poll?, write atm cell data to, or read atm cell data from. actually, ?multi-phy? operation provides an addressing scheme allows the atm layer processor to uniquely identify ?utopia interface blocks? (e.g., transmit and receive) within all of the uni devices, operating in the ?multi-phy? system. in order to uniquely identify a given ?utopia interface block?, within a ?multi-phy? system, each ?utopia interface block is assigned a 5-bit ?utopia address? value. the user assigns this address value to a particular ?transmit utopia interface block? by writing this address value into the ?tx utopia address register? (address = 82h) within its ?host? uni device. the bit-format of the ?tx utopia address register? is presented below. likewise, the user assigns a ?utopia address? value to a particular ?receive utopia interface block?, within one of the unis (in the ?multi-phy? system) by writing this address value into the ?rx utopia address register? (address = 7eh) within the ?host? uni device. the bit-format of the ?rx utopia address register? is presented below. note: the role of the receive utopia interface block, in ?multi-phy? operation is presented in section 7.3.2.2.2.2. 6.1.2.3.2.1 atm layer processor ?polling? of the unis, in the multi-phy mode when the uni is operating in the ?multi-phy? mode, the transmit utopia interface block will automatically be configured to support ?polling?. ?polling? allows an atm layer processor (which is interfaced to several uni devices) to deter- mine which unis are capable of receiving and handling additional atm cell data, at any given time. the manner in tx utopia address register (address = 82h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused tx_utopia_addr[4:0] ro ro ro r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0 rx utopia address register (address = 7eh) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused rx_utopia_addr[4:0] ro ro ro r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 165 which the atm layer processor ?polls? its uni devices, follows. figure 24. an illustration of multi-phy operation with uni devices #1 and #2 figure 24 depicts a ?multi-phy? system consisting of an atm layer processor and two (2) uni devices, which are designated as ?uni #1? and ?uni #2?. in this figure, both of the unis are connected to the atm layer processor via a common ?transmit utopia? data bus, a common ?receive utopia? data bus, a common ?txclav? line, a common ?rxclav? line, as well as common txenb*, rxenb*, txsoc and rxsoc lines. the atm layer processor will also be addressing both the transmit and receive utopia interface blocks via a common ?utopia? address bus (ut_addr[4:0]) therefore, the transmit and receive utopia interface blocks, within a given uni might have different addresses; as depicted in figure 24. the utopia address values, that have been assigned to each of the transmit and receive utopia interface blocks, within figure 24, are listed below in table 15. recall, that the transmit utopia interface blocks were assigned these addresses by writing these values into the ?tx utopia address register? (address = 82h) within their ?host? uni device. the discussion of the receive utopia table 15. utopia address values of the utopia interface blocks illustrated in figure 24. block utopia address value transmit utopia interface block?uni #1 00h receive utopia interface block?uni #1 01h transmit utopia interface block?uni #2 02h receive utopia interface block?uni #2 03h txdata[15:0] txaddr[4:0] txprty txenb* txsoc txclav rxdata[15:0] rxaddr[4:0] rxprty rxenb* rxsoc rxclav uni # 1 txaddr = 00h rxaddr = 01h txdata[15:0] txaddr[4:0] txprty txenb* txsoc txclav rxdata[15:0] rxaddr[4:0] rxprty rxenb* rxsoc rxclav txaddr = 02h rxaddr = 03h txdata[15:0] ut_addr[4:0] tx_parity tx_ut_wr* tx_soc_out txclav_in rxdata[15:0] rx_parity rx_ut_rd* rx_soc_in rxclav_in atm layer processor uni # 2
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 166 interface blocks, within unis #1 and #2 is presented in section 7.3.2.2.2.2.1. polling operation consider that the atm layer processor is currently writing a continuous stream of atm cell data into uni #1. while writing this cell data into uni #1, the atm layer processor can also ?poll? uni #2 for ?availability? (e.g., tries to determine if the atm layer processor can write any more atm cell data into the ?transmit utopia interface block? within uni #2). the atm layer processor?s role in the ?polling? operation the atm layer processor accomplishes this ?polling? operation by executing the following steps. 1. assert the txenb* input pin (if it is not asserted already). the uni device (being ?polled?) will know that this is only a ?polling? operation, if the txenb* input pin is asserted, prior to detecting its utopia address on the ?utopia address? bus. 2. the atm layer processor places the address of the transmit utopia interface block of uni #2 onto the utopia address bus, ut_addr[4:0], 3. the atm layer processor will then check the value of its ?txclav_in? input pin (see figure 24). the uni devices role in the ?polling? operation uni #2 will sample the signal levels placed on its tx utopia address input pins (txaddr[4:0]) on the rising edge of its ?transmit utopia interface block? clock input signal, txclk. afterwards, uni #2 will compare the value of these ? transmit utopia address bus input pin? signals with that of the contents of its ?tx utopia address register (address = 82h). if these values do not match, (e.g., txaddr[4:0] ? 02h) then uni #2 will keep its ?txclav? output signal ?tri-stated?; and will continue to sample its ?transmit utopia address bus input? pins; with each rising edge of txclk. if these two values do match, (e.g., txaddr[4:0] = 02h) then uni #2 will drive its ?txclav? output pin to the appropriate level, reflecting its txfifo ?fill-status?. since the uni is automatically operating in the ?cell level handshaking? mode, while it is operating in the ?multi-phy? mode; the uni will drive the txclav output signal ?high? if it is capable of receiving at least one more complete cell of data from the atm layer processor. conversely, the uni will drive the ?txclav? output signal ?low? if its txfifo is too full and is incapable of receiving one more complete cell of data from the atm layer processor. when uni #2 has been selected for ?polling?, uni #1 will continue to keeps its ?txclav? output signal ?tri-stated?. therefore, when uni #2 is driving its ?txclav? output pin to the appropriate level; it will be driving the entire ?txclav? line, within the ?multi-phy? system. consequently, uni#2 will also be driving the ?txclav_in? input pin of the atm layer processor (see figure 24). if uni #2 drives the ?txclav? line ?low?, upon the application of its address on the utopia address bus, then the atm layer processor will ?learn? that it cannot write any more cell data to this uni device; and will deem this device ?unavailable?. however, if uni #2 drives the txclav line ?high? (during ?polling?), then the atm layer processor will know that it can write cell data into the transmit utopia interface block, of uni # 2. figure 25 presents a timing diagram, that depicts the behavior of the atm layer processor?s and the uni?s signals
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 167 during polling. figure 25. timing diagram illustrating the behavior of various signals from the atm layer processor and the uni, during polling. notes regarding figure 25: 1. the transmit utopia data bus is configured to be 16 bits wide. hence, the data, which the atm layer processor places on the transmit utopia data bus, is expressed in terms of 16-bit words: (e.g., w0 - w26.) 2. the transmit utopia interface block is configured to handle 54 bytes/cell. hence, figure 25 illustrates the atm layer processor writing 27 words (w0 through w26) for each atm cell. 3. the atm layer processor is currently writing atm cell data to the transmit utopia interface block, within uni #1 (txaddr[4:0] = 00h) during this ?polling process?. 4. the txfifo, within uni#2?s transmit utopia interface block (txaddr[4:0] = 02h) is incapable of receiving any additional atm cell data from the atm layer processor. hence, the txclav line will be driven ?low? whenever this particular transmit utopia interface block is ?polled?. 5. the transmit utopia address of 1fh, is not associated with any uni device, within this ?multi-phy? system. hence, the txclav line is tri-stated whenever this address is ?polled?. note: although figure 24 depicts connections between the receive utopia interface block pins and the atm layer processor; the receive utopia interface block operation, in the multi-phy mode, will not be discussed in this section. please see section 7.2.2.2.2.2 for a discussion on the receive utopia interface block during multi-phy operation. 6.1.2.3.2.2 writing atm cell data into a different uni after the atm layer processor has ?polled? each of the uni devices, within its system, it must now select a uni, and begin writing atm cell data to that device. the atm layer processor makes its selection and begins the writing process by: 1. applying the utopia address of the ?target? uni on the ?utopia address bus?. 2. negate the txenb* signal. this step causes the ?addressed? uni to recognize that it has been selected to receive the next set of atm cell data from the atm layer processor. 3. assert the txenb* signal. 4. assert the txsoc input pin. 5. begin applying the atm cell data in a byte-wide (or word-wide) manner to the transmit utopia data bus. txclk txaddr[4:0] txclav txenb* txdata[15:0] txsoc 00h 1fh 02h 1fh 00h 02h 1fh 02h 00h 1fh 00h 02h w27 w0 w1 w2 w3 w4 w5 w6 w7 w8 w9 w10 00h 02h 00h 02h 02h 00h 00h 1 2 3 4 5 6 7 8 9 10 11 12
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 168 figure 26 presents a flow-chart that depicts the ?uni device selection and write? process in multi-phy operation. figure 26. flow-chart of the ?uni device selection and write procedure? for the multi-phy operation. figure 27 presents a timing diagram that illustrates the behavior of various ?transmit utopia interface block? signals; during the ?multi-phy? uni device selection and write operation. figure 27. timing diagram of the transmit utopia data and address bus signals, during the ?multi-phy? uni device selection and write operations. notes regarding figure 27: 1. the transmit utopia data bus is configured to be 16 bits wide. hence, the data, which the atm layer proces- sor places on the transmit utopia data bus, is expressed in terms of 16-bit words (e.g., w0?w26). 2. the transmit utopia interface block is configured to handle 54 bytes/cell. hence, figure 27 illustrates the atm layer processor writing 27 words (e.g., w0 through w26) for each atm cell. in figure 27, the atm layer processor is initially writing atm cell data to the transmit utopia interface block within uni #2 (txaddr[4:0] = 02h). however, the atm layer processor is also polling the transmit utopia interface block within uni #1 (txaddr[4:0] = 00h) and some ?non-existent? device at txaddr[4:0] = 1fh. the atm layer processor completes its writing of the cell to uni #1 at clock edge #4. afterwards, the atm layer processor will cease to write any more cell data to uni #1, and will begin to write this data into uni #2 (txaddr[4:0] = 02h). the atm layer pro- cessor will indicate its intentions to select a new uni device for writing by negating the txenb* signal, at clock edge #5 (see the shaded portion of figure 27). at this time, uni #1 will notice two things: start poll all unis within the ?multi-phy? system. determine which unis are ?available? select ?availble? uni 1. apply utopia address of the transmit utopia interface block of ?selected? uni onto the ?utopia address? bus. 2. negate the txenb* signal begin writing atm cell data into ?selected? uni 1. assert txenb* 2. place first byte/word of atm cell onto the ?transmit utopia data bus & assert txsoc continue to write atm cell data check the txclav level after writing 48 bytes of cell data. is txclav ?high? ? wait for txclav to toggle ?high? is txclav ?high? ? is there any more atm cell data to be written to selected uni? yes no yes yes no no txclk txaddr[4:0] txclav txenb* txdata[15:0] txsoc 00h 1fh 02h 1fh 00h 02h 1fh 00h 02h 1fh 02h 00h w0 w1 w2 w3 w4 w5 w6 w26 w25 w24 w23 cell transmitted to 02h cell transmitted to 00h 00h 02h 00h 02h 00h 02h 02h 1 2 3 4 5 6 7 8 9 10 11 12
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 169 1. the utopia address for the transmit utopia interface block, within uni #1 is on the transmit utopia address bus (txaddr[4:0] = 00h). 2. the txenb* signal has been negated. uni #1 will interpret this signaling as an indication that the atm layer processor is going to be performing write operations to it. afterwards, the atm layer processor will begin to write atm cell data into transmit utopia interface block, within uni #1. 6.1.2.4 transmit utopia interrupt servicing the transmit utopia interface block will generate interrupts upon the following conditions: ? detection of parity errors ? change of cell alignment (e.g., the detection of ?runt? cells) ? txfifo overrun if one of these conditions occur and if that particular condition is enabled for interrupt generation, then when the local m p / m c reads the uni interrupt status register, as shown below; it should read ?0xxxxx1xb? (where the b suffix denotes a binary expression, and the ?x? denotes a ?don?t care? value). at this point, the local m c/ m p has determined that the transmit utopia interface block is the source of the interrupt, and that the interrupt service routine should branch accordingly. the next step in the interrupt service routine should be to determine which of the three transmit utopia interface block interrupt conditions has occurred and is causing the interrupt request. in order to accomplish this, the local m p/ m c should now read the tx ut interrupt enable/status register, which is located at address 80h within the uni device. the bit format of this register is presented below. the ?tx ut interrupt enable/status? register has eight bit-fields. however, only six of these bit fields are relevant to interrupt processing. bits 0?2 are the interrupt status bits and bits 3?5 are the interrupt enable bits; for the transmit utopia interface block. each of these ?interrupt processing relevant? bit fields are defined below. bit 0?tcoca interrupt status?transmit utopia change of cell alignment condition if the atm layer processor asserts the txsoc input pin prior to writing the contents of a complete cell (as config- uni interrupt status register (address = 05h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused one sec interrupt status tx e3 interrupt status rx e3 interrupt status tx cp interrupt status rx cp interrupt status tx utopia interrupt status rx utopia interrupt status ro rur ro ro ro ro ro ro 0 x x x x x 1 x tx ut interrupt enable /status register (address?80h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 tx fifo reset discard upon parity error tx ut parity error interrupt enable tx fifo overrun interrupt enable tcoca interrupt enable tx ut parity error inter- rupt status tx fifo overrun interrupt status tcoca interrupt status r/w r/w r/w r/w r/w rur rur rur
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 170 ured via the cellof52bytes option) on the transmit utopia data bus, then the transmit utopia interface block will interpret this newly received cell data as a ?runt? cell. when the transmit utopia interface block detects a ?runt? cell, it will generate the ?transmit utopia change of cell alignment condition? interrupt, and the ?runt? cell will be dis- carded. the transmit utopia interface block will indicate that it is generating this kind of interrupt by asserting bit 0 (tcoca interrupt status) within the transmit utopia interrupt enable/status register, as depicted below. bit 1?tx fifo overrun interrupt status if the tx fifo is filled to capacity, and if the atm layer processor attempts to write any additional data to the tx fifo, some of the data within the tx fifo will be overwritten, and in turn lost. if the transmit utopia interface block detects this condition, and if this interrupt condition has been enabled, then the uni will assert the int* pin to the local m p/ m c. additionally, the uni will set bit-field 1, (txfifo overrun interrupt status) within the tx utopia interrupt enable/status register to ?1?, as depicted below. bit 1 of the tx ut interrupt enable/status register will be reset or cleared upon the local m p/ m c reading this regis- ter. this action will also negate bit 3 within the uni interrupt status register and the intb* output pin, unless other outstanding interrupt conditions are awaiting service. bit 2?tperr interrupt status?detection of parity error via the transmit utopia interface block the atm layer processor is expected to compute and present the odd-parity value of each byte or word of atm cell data that it intends place on the transmit utopia data bus. as the atm layer processor is writing atm cell data into the transmit utopia interface block, it will place the value of this parity bit at the txprty input pin of the uni device while the corresponding byte (or word) is present on the transmit utopia data bus. the transmit utopia interface block will read the contents of the transmit utopia data bus, and will independently compute the odd-par- ity value of that byte or word. afterwards, the transmit utopia interface block will then compare its computed parity value with that presented at the txprty input (by the atm layer processor). if these two parity values are different then a ?transmit utopia parity error? has been detected. if this interrupt condition has been enabled, then the uni will generate the ?detection of parity error? interrupt. additionally, the uni will set bit-field 2 (tx ut parity error tx ut interrupt enable /status register (address = 80h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 txfifo reset discard upon par t tx ut parity error inter- rupt enable tx fifo overrun interrupt enable tcoca interrupt enable tx ut par- ity error interrupt status tx fifo overrun interrupt status tcoca interrupt status r/w r/w r/w r/w r/w rur rur rur x x x x 1 x x 1 tx ut interrupt enable /status register (address = 80h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 txfifo reset discard upon parity error tx ut par- ity error interrupt enable tx fifo overrun interrupt enable tcoca interrupt enable tx ut parity error interrupt status tx fifo overrun interrupt status tcoca interrupt status r/w r/w r/w r/w r/w rur rur rur x x x 1 x x 1 x
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 171 interrupt status), within the transmit utopia interrupt enable/status register to ?1?, as depicted below. once the local m p/ m c has read the contents of the tx ut interrupt enable/status register, then bit 3 of the uni interrupt status register, bit 2 of the tx ut interrupt enable/status register, and the intb* output pin will all be negated, unless outstanding interrupts conditions are awaiting servicing. bit 3?tcoca interrupt enable?transmit utopia change of cell alignment interrupt enable this ?read/write? bit-field allows the user to enable or disable the ?change of cell alignment? interrupt. the local microprocessor can enable this interrupt by writing a ?1? to this bit-field. upon power up or reset conditions, this bit- field will contain a ?0?. therefore the default condition is for this interrupt to be disabled. bit 4?tx fifo errint enable?tx fifo overrun condition interrupt enable this ?read/write? bit-field allows the user to enable or disable the ?tx fifo overrun? interrupt. the local micropro- cessor can enable this interrupt by writing a ?1? to this bit. upon power up or reset conditions, this bit will contain a ?0?. therefore the default condition is for this interrupt to be disabled. the local microprocessor must write a ?1? to this bit in order to enable this interrupt. bit 5?tperr interrupt enable?detection of parity error in transmit utopia block interrupt enable this ?read/write? bit-field allows the user to enable or disable the ?detected parity error? interrupt. the user can enable this interrupt by writing a ?1? to this bit. upon power up or reset conditions, this bit will contain a ?0?. therefore the tx ut interrupt enable /status register (address = 80h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 tx fifo reset discard upon parity error tx ut parity error inter- rupt enable tx fifo overrun interrupt enable tcoca interrupt enable tx ut parity error inter- rupt status tx fifo overrun interrupt status tcoca interrupt status r/w r/w r/w r/w r/w rur rur rur x x 1 x x 1 x x tx ut interrupt enable /status register (address = 80h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 tx fifo reset discard upon parity error tx ut parity error inter- rupt enable tx fifo overrun interrupt enable tcoca interrupt enable tx ut parity error inter- rupt status tx fifo overrun interrupt status tcoca interrupt status r/w r/w r/w r/w r/w rur rur rur tx ut interrupt enable /status register (address = 80h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 tx fifo reset discard upon parity error tx ut parity error inter- rupt enable tx fifo overrun interrupt enable tcoca interrupt enable tx ut parity error inter- rupt status tx fifo overrun interrupt status tcoca interrupt status r/w r/w r/w r/w r/w rur rur rur
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 172 default condition is for this interrupt to be disabled. the user must write a ?1? to this bit in order to enable this interrupt. 6.2 transmit cell processor 6.2.1 brief description of the transmit cell processor the transmit cell processor reads in cells from the transmit utopia fifo (tx fifo) within the transmit utopia interface block. immediately after reading in the cell from the txfifo, the transmit cell processor will verify the ?data path integrity check? pattern (located in octet # 5, within this cell). afterwards, the transmit cell processor optionally computes and inserts the hec byte into each cell, and optionally scrambles the cell payload bytes. when the txfifo does not contain a full cell, the transmit cell processor generates a programmable idle (or unassigned) cell and inserts it in the transmit stream. the transmit cell processor provides the user with the ability to write an ?outbound? oam cell into the ?transmit oam cell? buffer, and to transmit this oam cell, upon demand. additionally, the transmit cell processor is also equipped with a serial input port which allows the user to externally insert the value of the gfc (generic flow control) field for each outbound valid cell. figure 28 presents a simple illustration tx ut interrupt enable /status register (address = 80h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 tx fifo reset discard upon parity error tx ut parity error inter- rupt enable tx fifo overrun interrupt enable tcoca interrupt enable tx ut parity error inter- rupt status tx fifo overrun interrupt status tcoca interrupt status r/w r/w r/w r/w r/w rur rur rur
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 173 of the transmit cell processor block and the associated external pins. figure 28. simple illustration of the transmit cell processor block and the associated external pins transmit cell processor txcelltxed txgfcclk txgfcmsb txgfc from transmit utopia interface block to transmit e3 framer
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 174 figure 29 presents a functional block diagram of the transmit cell processor. figure 29. functional block diagram of the transmit cell processor 6.2.2 functional description of transmit cell processor the transmit cell processor consists of the following functional blocks. ? configuration and status register ? controller ? hec calculator ? oam processor ? cell scrambler ? idle cell generator ? ?transmit gfc nibble-field? serial input port most of these functional blocks will be discussed in some detail below. the transmit cell processor will read in atm cell data from the tx fifo. the first four bytes of each cell is loaded into the ?hec byte calculator?. the fifth byte of each user cell will be read-in and compared against a pre-defined ?data path integrity check? pattern. while this ?check? is being performed; the ?hec byte calculator? will take these first four bytes of the cell, and compute a hec byte value. this hec byte value will be written (or inserted) into the 5th octet position of the cell. conse- databusl[7:0] databush[7:0] readb writeb csb configuration and status registers tusoc tcelpresent tfdat cellof52 txgfc txgfcclk txgfcmsb sendoam tdpchkpat icheccalcen hecinsen oamsent tdpintegfail controller cosetin gfcinsen hecerrmask hec calculator hecen gfc[3:0] hecsoc ticcount tcellcount txceltxed tcelrdclk from framer scrambler idle cell generator oam processor tceldata[7:0] scrambleren txcpint to interrupt block hecdat[7:0] headerloc oamcycle oamdatal[7:0] oamdatah[7:0] icdat[7:0] from txutopia to/from pins
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 175 quently, the ?data path integrity check? pattern will now be overwritten. bytes 6 through 53 (the cell payload) of each cell, are sent onto the ?cell scrambler? and are summarily ?scrambled?. afterwards, the cell is reassem- bled (with the first four header bytes, the newly computed hec byte and the scrambled payload bytes), and is routed to the transmit e3 framer. when a complete cell is not available in the txfifo, a cell is created by ?idle cell generator?. the user has the option of specifying the contents of the header and payload of these idle cells via the m p?accessible regis- ters. the payload of the idle cell will be programmed with a repeating pattern of a byte contained within an on- chip register. from this point on, the idle cell is processed in the same manner as is an assigned (e.g., user or oam) cell. a valid hec byte is computed over the four bytes of the programmed idle cell header and is inserted into the fifth octet position. the user has the option to disable the hec byte calculation and insertion features for idle cells, and the contents of the fifth-header byte programmed register may be transmitted directly. the transmit cell processor allows the user to transmit pre-programmed oam cells upon demand. the con- tent of this oam cell is stored in an on-chip ram location, which will be referred to as the ?transmit oam cell buffer?. when the local m p decides to transmit the oam cell to the ?far end? terminal, it writes a ?1? to a certain register bit. the transmit cell processor will then proceed to read in the contents of the ?transmit oam cell? buffer, and form a cell from this data. this oam cell will be subsequently processed like any user or idle cell (e.g., processed through the hec byte calculator and cell scrambler) and then routed to the transmit e3 framer for transmission onto the e3 line. as mentioned earlier, the transmit cell processor will perform a ?data path integrity check? on all user cells that it reads from the txfifo. more specifically, the transmit cell processor will look for a specific data pattern that should be residing within octet #5 of these cells. the purpose of this test is to verify the integrity of the communication link throughout the ?atm layer processor? system. this ?data path integrity pattern? was writ- ten into the cell by the receive cell processor of another uni, prior to its entry into the ?atm layer processor? system. if the transmit cell processor detects a discrepancy between the contents of octet #5 and the expected pattern, then the transmit cell processor will generate a ?data path integrity check? error interrupt. after the transmit cell processor has completed its checking of the ?data path integrity check? pattern; within a given cell, it will (typically) overwrite this pattern with the hec byte. the transmit cell processor will inform external circuitry when a cell has been transmitted from the transmit cell processor to the transmit e3 framer, by pulsing the ?txcelltxed? output pin. therefore, the ?txcelltxed? signal will be pulsing at a nominal rate of 80 khz. 6.2.2.1 hec byte calculation and insertion the ?hec byte calculator? takes the first four bytes of each cell and computes a crc-8 value via the generat- ing polynomial x 8 + x 2 + x + 1. the user has the option to have the coset polynomial x 6 + x 4 + x 2 + 1 modulo-2 added to the crc-8 byte and, instead insert this newly computed value into byte 5 of the cell before transmis- sion. the user also has the following additional options regarding the ?hec byte calculator?. ? hec byte calculation and insertion enable/disable for user and oam cells. ? hec byte calculation and insertion enable/disable for idle cells. ? inserting errors into the hec byte, for chip/equipment testing purposes. the implementation and result of selecting each of these options are presented below. 6.2.2.1.1 configuring the hec byte calculator for user and oam cells the user can enable or disable the ?hec byte calculation and insertion? feature for user and oam cells by writing the appropriate value to bit 5 (hec insert enable) within the ?tx cp control/interrupt? register, as depicted below. tx cp control/interrupt register (address = 72h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 176 if the user opts to disable this feature, then the hec byte will not be computed and the contents within the fifth octet position of each cell (e.g., typically the ?data path integrity check? pattern) will be transmitted to the transmit e3 framer block as is. the following table relates the content of this bit-field to the ?hec byte calculator?s? handling of valid (e.g., user or oam) cells. upon power up or reset, the ?hec byte calculator and insertion? feature is enabled. the user must write a ?0? to this bit in order to disable this operation. 6.2.2.1.2 configuring the ?hec byte calculator and insertion? feature for idle cells the user can separately enable or disable the ?hec byte calculation and insertion? feature for the outbound idle cells. the user can exercise this option by writing the appropriate value to bit 1 (idle cell hec calen) within the ?tx cp control/interrupt? register, as depicted below. this ?read/write? bit-field allows the user to enable or disable the ?calculation and insertion? of the hec byte into the idle cell as illustrated below. if the user chooses to disable this feature, then the 5th octet of the idle cells will be transmitted to the transmit e3 framer block as programmed in the ?tx cp idle cell pattern header?byte 5? register (address = 7ah). table 17 relates the content of this bit-field to the ?hec byte calculator?s? handling of idle cells. scrambler enable coset enable hec insert enable tdpchk pattern gfc insert enable tdperr interrupt enable idle cell hec calen tdperr interrupt status r/w r/w r/w r/w r/w r/w r/w rur 1 1 x 1 0 0 1 0 table 16. the relationship between the contents of bit-field 5 (hec ins enable) within the tx cp control/interrupt register, and the hec byte calculator?s handling of valid cells hec insert enable result 0 hec byte calculation is disabled and the 5th byte is transmitted to the transmit e3 framer as is. 1 the hec byte is calculated and is inserted into the 5th octet position of each valid cell. tx cp control/interrupt register (address = 72h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 scrambler enable coset enable hec insert enable tdpchk pattern gfc insert enable tdperr interrupt enable idle cell hec calen tdperr interrupt status r/w r/w r/w r/w r/w r/w r/w rur 1 1 1 1 0 0 x 0 table 17. the relationship between the content within bit 1 (ic hec calc en) within the ?tx cp control/interrupt? register and the resulting handling of idle cells, by the ?hec byte calculator? idle cell hec calen result 0 the entire programmed idle cell header is transmitted without modification tx cp control/interrupt register (address = 72h)
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 177 upon power up or reset, the transmit cell processor will be configured such that the hec bytes will be calculated and inserted each idle cell. the user must write a ?0? to this bit-field in order to disable this feature. 6.2.2.1.3 modulo?2 addition of coset polynomial to the hec byte value when enabled, the hec byte calculator takes the first four bytes of each cell and computes a crc-8 value via the generating polynomial x8 + x2 + x + 1. the bisdn physical layer specifications (itu recommendations i.432) specifies that this crc-8 (or hec) value can optionally be modulo-2 added to the polynomial x6 + x4 + x2 + 1; and inserting the result of this calculation into the fifth byte of each cell. the purpose of this option is to provide protection against bit slips. this protection is not required in transmission systems that ensure adequate one?s density. however, this operation does provide protection against all zeros cells that could be passed to the atm layer during a loss of signal condition on the transmission medium. the atm forum uni specifications also requires this operation. the user can enable or disable this modulo-2 addition, by writing the appropriate value to bit 6 (coset enable) within the ?tx cp control/interrupt? register, as depicted below. a ?1? in this bit-field will enable this modulo addition. conversely, a ?0? in this bit-field will disable this operation. upon power up or reset, the transmit cell processor will be configured to modulo-2 add the coset polynomial to the hec byte prior to insertion into the cell. the user must write a ?0? into this bit-field in order to disable this opera- tion. 6.2.2.1.4 inserting errors into the hec byte via software control the XR-T7234 e3 uni allows the user to insert errors into the hec bytes of ?outbound? cells in order to support equipment testing. one such test that the user may wish to run is to verify is that the hec byte verification (e.g., error detection and/or correction) features of some ?far-end? terminal equipment is functioning properly. the user would conduct this test by transmitting cells with erroneous hec byte values to the ?unit under test? (uut). the user can exercise this option by writing the appropriate data into the tx cp error mask register, which is located at address 62h within the uni. 1 the hec byte is calculated, via the first four bytes of the header, and is inserted into the fifth octet position within each idle cell. tx cp control/interrupt register (address = 72h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 scrambler enable coset enable hec insert enable tdpchk pattern gfc insert enable tdperr interrupt enable idle cell hec calen tdperr interrupt status r/w r/w r/w r/w r/w r/w r/w rur 1 x 1 1 0 0 1 0 tx cp hec byte error mask register; (address = 74h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 hec error mask byte r/w r/w r/w r/w r/w r/w r/w r/w table 17. the relationship between the content within bit 1 (ic hec calc en) within the ?tx cp control/interrupt? register and the resulting handling of idle cells, by the ?hec byte calculator? idle cell hec calen result
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 178 the transmit cell processor automatically xors the hec byte (or each ?outbound? cell) with the contents of this register. the results of this operation is written back into the fifth octet position of each of these cells. therefore, if the user does not wish to inject errors into the hec byte, he/she should insure that the contents of this register is 00h, the default value. 6.2.2.2 the cell scrambler the cell scrambler takes bytes 6 through 53 of each cell (the payload) and scrambles the contents of these bytes. the purpose of scrambling the cell payload bytes is to reduce the possibility of the contents of the cell payload mimicking patterns that are used for framing and cell delineation purposes. the scrambler generating polynomial is x 43 + 1. the user can enable or disable the cell scrambler by setting or clearing bit 7 (scrambler enable) within the ?tx cp control/interrupt? register, as depicted below. a ?1? in this bit-field enables the cell scrambler. conversely, a ?0? in this bit-field disables the cell-scrambler. upon power up or reset, the cell scrambler function will be enabled. therefore, the user must write a ?0? to this bit in order to disable cell scrambling. 6.2.2.3 gfc nibble-field serial input port (only available in the 160 pin package version) the first four bits in the first header byte of each cell are allocated for carrying ?generic flow control? (gfc) infor- mation. the user can externally insert his/her own values for the gfc nibble-field into each outbound valid (user or oam) cell, via a serial input port. the user will activate this serial input port (the ?transmit gfc-nibble-field? serial input port) by writing a ?1? to bit 3 (gfc insert enable) within the ?tx cp control/interrupt? register, as depicted below. once the user has activated the ?transmit gfc nibble-field? serial input port, it will accept the 4 bit gfc value via the txgfc input pin during each valid cell processing period. the txgfc serial input port will be expecting the bits of the gfc nibble-field in descending order (msb first). the gfc bits are clocked into the serial input port via the rising edge of the clock output signal, txgfcclk. since these four bits must be provided for each cell; txgfcclk will provide four clock edges during each cell processing period. the ?transmit gfc nibble-field? serial input port will also provide a ?framing pulse? in the form of the txgfcmsb output pin pulsing ?high?. this output pin will pulse ?high? when the transmit cell processor is ready to receive the msb (most significant bit) of the gfc nibble. figure 30 tx cp control/interrupt register (address = 72h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 scrambler enable coset enable hec insert enable tdpchk pattern gfc insert enable tdperr interrupt enable idle cell hec calen tdperr interrupt status r/w r/w r/w r/w r/w r/w r/w rur x 1 1 1 0 0 1 0 tx cp control/interrupt register (address = 72h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 scrambler enable coset enable hec insert enable tdpchk pattern gfc insert enable tdperr interrupt enable idle cell hec calen tdperr interrupt status r/w r/w r/w r/w r/w r/w r/w rur 1 1 1 1 x 0 1 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 179 presents a timing diagram illustrating the role of each of these signals during gfc nibble insertion. figure 30. behavior of txgfc, txgfcclk, and txgfcmsb during gfc nibble insertion into the ?outbound? valid cell note: 1. the ?transmit gfc nibble-field? serial input port will only insert the gfc value into valid (e.g., user or oam) cells. it will not insert the gfc value into idle cells. 2. the ?transmit gfc nibble-field? serial input port is only available in the 160 pin package version of the XR-T7234 e3 uni. 6.2.2.4 oam cell processing the uni chip provides on-chip ram space for the storage of the complete contents (header and payload) of an oam cell. this ram space is known as the ?transmit oam cell? buffer (consisting of 54 bytes) and is located at 136h through 16bh within the uni address space. therefore, in order to ?load? the oam cell into the ?transmit oam cell? buffer. the local m p must write this data into this address location within the uni ic, via the microprocessor interface. afterwards, whenever the user wishes to transmit the oam cell, the local m p must to write a ?1? to bit 7 (sendoam) within the tx cp oam register as depicted below. if the local m p writes a ?1? bit 7 (or ?1xxxxxxxb?) to the tx cp oam register; then the transmit cell processor will read-in the contents of the ?transmit oam cell? buffer, and form it into a cell. this oam cell will then be routed to the hec byte calculator and cell scrambler within the transmit cell processor block, prior to transmittal to the transmit e3 framer. bit 7 of the tx cp oam register will be reset (to ?0?) upon completion of the transmission of the oam cell. the user may also poll this bit in order to determine whether or not the oam cell has been sent. the user can monitor the number of valid cells (e.g., user and oam cells) that have been generated and transmitted to the transmit e3 framer. the transmit cell processor increments the contents of the ?pmon transmitted valid cell count (msb and lsb)? registers (address = 54h, and 55h) for each valid cell that it generates. these two registers are ?reset-upon-read? registers that when concatenated present a 16-bit representation of the total number of tx cp oam register (address = 73h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 sendoam unused semaphore ro ro ro ro ro ro ro txgfcclk txgfcmsb t14 txgfc t16 bit 3 bit 2 bit 1 bit 0 t17 t13 t15
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 180 ?valid cells? generated and transmitted by the transmit cell processor, since the last read of these registers. the bit-format of these two registers follows. 6.2.2.5 idle cell processing whenever the txfifo (within the transmit utopia interface block) does not contain a complete cell, the transmit cell processor will automatically generate and process idle cells. the user can customize the contents of these idle cells or he/she can use the default values, that are provided by the uni chip. the user can customize the contents of these idle cells by programming six different registers: ? tx cp idle cell pattern?header byte 1 ? tx cp idle cell pattern?header byte 2 ? tx cp idle cell pattern?header byte 3 ? tx cp idle cell pattern?header byte 4 ? tx cp idle cell pattern?header byte 5 ? tx cp transmit cell payload table 18 presents the bit format of each of these registers and table 19 presents the address and default values of these cells. pmon transmitted valid cell count - msb (address = 54h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 tx valid cell count?high byte rur rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0 pmon transmitted valid cell count ?lsb (address = 55h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 tx valid cell count?low byte rur rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0 table 18. bit format of the tx cp idle cell pattern -header bytes and tx cp cell payload? registers register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 tx cp idle cell pattern?header byte 1 transmit idle cell pattern?header byte 1 tx cp idle cell pattern?header byte 2 transmit idle cell pattern?header byte 2 tx cp idle cell pattern?header byte 3 transmit idle cell pattern?header byte 3 tx cp idle cell pattern?header byte 4 transmit idle cell pattern?header byte 4 tx cp idle cell pattern?header byte 5 transmit idle cell pattern?header byte 5 tx cp idle cell payload transmit idle cell payload
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 181 the role of the registers for idle cell pattern?bytes 1 through 4 is quite straightforward. when the transmit cell processor opts to generate an idle cell, it will read in the content of these registers, and send these values onto the hec byte calculator. consequently, the contents of the ?transmit idle cell pattern?header byte 5? will likely be overwritten by the hec byte calculator in the idle cell, unless the hec byte calculator has been disabled (see section 6.2.2.1.2). the payload portion of these idle cells is defined by the contents of the transmit idle cell payload register (address = 7bh), repeated 48 times. when the transmit cell processor reads in this register to form the cell payload, the resulting payload will be sent on to the cell scrambler and is (optionally) scrambled just like any assigned cell. the uni will keep track of the number of idle cells that have been generated and transmitted to the transmit e3 framer. the transmit cell processor increments the contents of the ?pmon transmitted idle cell count (msb and lsb)? registers (address = 52h and 53h) for each idle cell that is generated and transmitted. these two registers are ?reset-upon-read? registers that, when concatenated, presents a 16-bit representation of the total number of idle cells generated and transmitted since the last time these registers were read. the bit format of these two registers follow. 6.2.2.6 data path integrity check the transmit cell processor provides for some performance monitoring of the communication link between the various unis, over the ?atm switching system?. this performance monitoring feature is referred to as the ?data table 19. address and default values of the tx cp idle cell pattern registers address register default value 76h tx cp idle cell pattern?header byte 1 00h 77h tx cp idle cell pattern?header byte 2 00h 78h tx cp idle cell pattern?header byte 3 00h 79h tx cp idle cell pattern?header byte 4 01h 7ah tx cp idle cell pattern?header byte 5 00h 7bh tx cp idle cell payload 00h pmon transmitted idle cell count - msb (address = 52h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 tx idle cell count?high byte rur rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0 pmon transmitted idle cell count?lsb (address = 53h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 tx idle cell count?low byte rur rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 182 path integrity check?. the receive cell processor, or some equivalent entity, within a uni device, will (after performing hec byte verification) write a ?data path integrity check? pattern into each cell prior to its being read and processed by the atm layer processor. this cell (with the ?data path integrity check? pattern) will be routed through the atm switch, and possibly throughout the wide area network (wan); before arriving to the transmit utopia interface block of a given XR-T7234 e3 uni. the transmit cell processor will read in this cell from the tx fifo, and will, prior to inserting a new hec byte into the cell, read in the fifth octet, from the tx fifo and check it for a specific pattern or value. the user can configure the transmit cell processor to check for either a constant ?55h? pattern or an alternating pattern of ?55h? and ?aah? for each cell. the user can also configure the transmit cell processor to generate an interrupt if a data path integrity test fails. the user can accomplish all of this by writing the appropriate data to the ?tx cp control/ interrupt? register (address = 72h). the bit format (with the relevant bit fields shaded) of this register is shown below. note: 1. the ?data path integrity check? feature is disabled if the transmit (and receive) utopia interface blocks have been configured handle 52 byte cells. 2. this ?data path integrity test? is only performed on user cells. the transmit cell processor does not perform this test on oam or idle cells. the role that each of these ?shaded? bit field play is presented below. bit 4?tdpchk pat?test data path integrity check pattern the transmit cell processor is always checking for a specific pattern in the fifth octet of a user cell retrieved fromthe tx fifo. this ?read/write? bit allows the user to specify the octet pattern that the transmit cell processor should be checking for. the following table relates the contents of this bit field to the octet pattern expected by the transmit cell processor. the remaining shaded bits are ?interrupt service? related and will be discussed in the following section. 6.2.2.7 transmit cell processor interrupt servicing the transmit cell processor generates interrupts upon the detection of an error in the ?data path integrity check? pattern. if this condition occurs, and if that particular is enabled for interrupt generation, then the uni will generate the ?data path integrity check pattern error? interrupt. afterwards, when the local m p/ m c reads the uni interrupt status register, as shown below; it should read ?0xxx1xxxb? (where the b suffix denotes a binary expression, and the ?x? denotes a tx cp control/interrupt register (address = 72h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 scrambler enable coset enable hec insert enable tdpchk pattern gfc insert enable tdperr interrupt enable idle cell hec calen tdperr interrupt status r/w r/w r/w r/w r/w r/w r/w rur table 20. the relationship between the contents of bit 4 (tdpchk pat) within the ?tx cp control/interrupt? register, and the ?data path integrity check? pattern that the transmit cell processor will look for in the 5th octet of each incoming user cell tdpchk pattern ?data path integrity pattern? expected by the transmit cell processor 0 transmit cell processor expects an alternating ?55h?/?aah? pattern for the value of the fifth octet of the cells received from the tx fifo. 1 transmit cell processor expects a constant ?55h? pattern for the value of the fifth octet of the cells received from the tx fifo.
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 183 ?don?t care? value). at this point, the local m c/ m p has determined that the transmit cell processor block is the source of the interrupt, and that the interrupt service routine should branch accordingly. since the transmit cell processor contains only one interrupt source, the interrupt service routine, in this case should perform a read of the ?tx cp control/interrupt? register (address = 72h), in order to verify and service this condition. the bit format of this register is presented below. this register contain 8 active bit-fields. however, only two of these bit-fields are relevant to interrupt processing. bit 0 is an interrupt status bit, and bit 2 is an interrupt enable bit. bit 2?tdperrinten? ?test data path integrity check? interrupt enable this ?read/write? bit-field allows the user to enable or disable the ?data path integrity check pattern error? interrupt. writing a ?0? to this bit-field disables this interrupt. likewise, writing a ?1? to this bit-field enables this interrupt. bit 0?tdperrintstat??test data path integrity check? interrupt status this ?reset-upon-read? bit-field indicates whether or not the ?data path integrity check pattern error? interrupt has occurred since the last reading of the ?tx cp control/interrupt? register. this interrupt will occur if the transmit cell processor detects a byte-pattern, in the fifth octet position of each cell read from the txfifo, that differs from the expected ?data path integrity check? pattern. a ?1? in this bit-field indicates that this interrupt has occurred since the last reading of the tx cp control/interrupt register. a ?0? in this bit-field indicates that this interrupt has not occurred. note: once the local m p has read this register, bit 0 (tdperr interrupt status) will be reset to ?0?. additionally, bit 3 (tx cp interrupt status) within the ?uni interrupt status? register will also be reset to ?0?. 6.3 transmit e3 framer 6.3.1 brief description of the transmit e3 framer the transmit e3 framer takes the incoming atm cell data from the transmit cell processor and maps it into the payload portion of the outbound e3 frame. the transmit e3 framer supports the itu-t g.832 compliant frame for- mat. the transmit e3 framer operates at 34.368 mhz and framing is derived from one of three (3) possible input uni interrupt status register (address = 05h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused one sec. interrupt status tx e3 interrupt status rx e3 interrupt status tx cp interrupt status rx cp interrupt status tx utopia interrupt status rx utopia interrupt status ro rur ro ro ro ro ro ro 0 x x x 1 x x x tx cp control/interrupt register (address = 72h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 scrambler enable coset enable hec insert enable tdpchk pattern gfc insert enable tdperr interrupt enable idle cell hec calen tdperr interrupt? status r/w r/w r/w r/w r/w r/w r/w rur
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 184 clock signals. the framing overhead bytes are generated and inserted with the e3 payload bits in order to make up the complete e3 frame. the e3 frame is then encoded into either the unipolar, ami or hdb3 line codes as it is transmitted to the ?far-end? terminal. the transmit e3 framer provides an interface that supports the transmission of path maintenance data link messages on the outbound e3 frames via the on-chip lapd transmitter. the trans- mit e3 framer also transmits the contents of 16 on-chip trail trace buffer registers out to the ?far-end? terminal. different transmission conditions like ais (alarm indication signal), and the yellow alarm can be generated upon software command. further, the los (loss of signal) condition can be simulated upon software command. 6.3.2 definition of the itu-t g.832 compliant e3 frame the role of the various oh (overhead) bytes, within the itu-t g.832 compliant e3 frame, are best described by discussing the e3 frame format as a whole. the e3 frame contains 537 bytes, of which 7 bytes are overhead and the remaining 530 bytes are ?payload? bytes. the atm cells are inserted into this 530 byte payload portion, for each frame. these 537 octets are arranged in 9 rows of 60 columns each, except for the last three rows which contain only 59 columns. the frame repetition rate for this type of e3 frame, is 8000 frames per second, thereby resulting in the standard e3 bit-rate of 34.386 mbps. figure 31 presents an illustration of the itu-t g.832 compliant e3 frame format . fa1 fa2 em 530 octet payload tr ma nr gc 1 byte 59 bytes
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 185 figure 31. illustration of the itu-t g.832 compliant e3 frame forma 6.3.2.1 definition of the overhead bytes the seven (7) overhead bytes are shown in figure 31, as fa1, fa2, em, tr, ma, nr, and gc. each of these over- head bytes are further defined below. 6.3.2.1.1 frame alignment (fa1 and fa2) bytes fa1 and fa2 are known as the frame alignment bytes. the receiver e3 framer, while trying to acquire or maintain framing with its incoming e3 frames, will attempt to locate these two bytes. fa1 is assigned the value of f6h, and fa2 is assigned 28h. 6.3.2.1.2 error monitor (em) byte the em byte contains the results of bip-8 (bit interleaved parity) calculations over an entire e3 frame. the bit interleaved parity (bip-8) byte field supports error detection, during the transmission of e3 frames, between the ?near-end? transmit e3 framer and the ?far end? receive e3 framer. the transmit e3 framer will compute the bip-8 value over the 537 octet structure, within each e3 frame. the resulting bip-8 value is then inserted into the em byte-field within the very next e3 frame. bip-8 is an eight bit code in which the nth bit of the bip-8 code reflects the even parity bit calculated with the nth bit of each of the 537 octets within the e3 frame. thus, the bip-8 value presents the results for 8 separate even-bit parity calculations. the receive e3 framer will compute its own version of the em byte for each e3 frame that it receives. afterwards, it will compare the value of its ?locally computed? em byte with the em byte that it receives in the very next e3 frame. if the two em byte values are equal, then the receive e3 framer will conclude that this e3 frame was received in an ?error-free? fashion. further, the receive e3 framer will inform the ?far-end? terminal of this fact by having the ?near-end? transmit e3 framer set the ?febe? (far-end-block error) bit, within the ma byte of an out- bound e3 frame, (to the ?far-end? terminal) to ?0?. please see section 6.3.2.1.4 for a discussion of the ma byte.
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 186 however, if the receive e3 framer detects an error in the incoming em byte, then it will conclude that the corre- sponding e3 frame is errored. further, the receive e3 framer will inform the ?far-end? terminal (e.g., the source of this errored e3 frame) of this fact by having the ?near-end? transmit e3 framer set the ?febe? bit, within an ?out- bound? e3 frame (destined for the ?far-end? terminal) to ?1?. a detailed discussion on the practical use of the em byte is presented in section 6.3.3.2. 6.3.2.1.3 the trail trace (tr) byte this byte-field is used to repetitively transmit a trail access point identifier so that a trail receiving terminal can verify its continued connection to the intended transmitter. the trail access point identifier uses the 16-byte numbering format as tabulated below. the first byte of this 16 byte string is a ?frame start marker? and is typically of the form [1, c6, c5, c4, c3, c2, c1, c0]. the ?1? in the msb (most significant bit) of this first byte is used to identify this byte as the ?frame start marker? (e.g., first byte of the 16-byte trail trace buffer sequence). the bits: c6 through c0 are the results of a crc-7 calcu- lation over the previous 16-byte frame. the subsequent 15 bytes are used for the transport of 15 ascii characters required for the e.164 numbering format. 6.3.2.1.4 maintenance and adaptation (ma) byte the ma byte is responsible for carrying the ferf (far-end receive failure) and the febe (far end block error status) indicators from one terminal to another. the ma byte-field also carries the ?payload type?, the ?payload dependent? and the ?timing marker? indicators. the byte format for the ma byte is presented below. bit 7?ferf (far-end receive failure) if the receive e3 framer (at a ?near-end? terminal) is experiencing problems receiving e3 frame data from a ?far-end? terminal (e.g., an los, oof or ais condition), then it inform the ?far-end? terminal of this fact by commanding the ?near-end? transmit e3 framer to set the ?ferf? bit-field (within the ma byte-field) of an ?outbound? e3 frame (which is destined for the ?far-end? terminal) to ?1?. the ?near-end? transmit e3 framer will continue to set the ferf bit-fields (within subsequent ?outbound? e3 frames) to ?1? until the receive e3 framer no longer experiences problems in receiving the e3 frame data. if the ?far-end? terminal receives a certain number of consecutive e3 frames, with the ferf bit-field set to ?1?, then the ?far-end? terminal will interpret this signaling as an indication ofa ?far-end receive failure? (e.g., a problem with the ?near-end? terminal). conversely, if the receive e3 framer (at a ?near-end? terminal) is not experiencing any problems receiving e3 frame data from a ?far-end? terminal; then it will also inform the ?far-end? terminal of this fact by commanding the ?near-end? transmit e3 framer to set the ?ferf? bit-field (within the ma byte-field) of an ?outbound? e3 frame (which is destined for the ?far-end? terminal) to ?0?. the ?far-end? terminal will interpret this form of signaling as trail trace bits byte number bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 1 (frame start marker) 1 c6 c5 c4 c3 c2 c1 c0 2 0 x x x x x x x ? 0 x x x x x x x ? 0 x x x x x x x 16 0 x x x x x x x bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 ferf febe payload type payload dependent timing marker
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 187 an indication of a normal operation. a detailed discussion into the practical use of the ferf bit-field is presented in section 6.3.3.3.1. bit 6?febe (far-end block error) if a ?near-end? receive e3 framer detects an error in the em byte, within an incoming e3 frame that it has received from the ?far-end? terminal, then it inform the ?far-end? terminal of this error by commanding the ?near-end? transmit e3 framer to set the ?febe? bit-field (within the ma byte-field) of an ?outbound? e3 frame (which is destined for the ?far-end? terminal) to ?1?. the ?far-end? terminal will interpret this signaling as an indication that the e3 frames that it is transmitting back out to the ?near-end? receive e3 framer, are errored. conversely, if the ?near-end? receive e3 framer does not detect any errors in the em byte, within the incoming e3 frame, then it will also inform the ?far-end? terminal of this fact; by commanding the ?near-end? transmit e3 framer to set the ?febe? bit-field of an outbound e3 frame; (which is destined for the ?far-end? terminal) to ?0?. a detailed discussion into the practical use of the febe bit-field is presented in section 6.3.3.2. bits 5?3: payload type these bit-fields indicates to the ?far-end? receiver, what kind of data is being transported in the 530 bytes of e3 frame payload data. some of the defined payload type values are tabulated below. bits 2?1: payload dependent bit 0?timing marker this bit-field is set to ?0? to indicate that the timing source is traceable to a primary reference clock. otherwise, this bit-field is set to ?1?. 6.3.2.1.5 the network operator (nr) byte the nr byte or the gc byte can be configured to transport lapd message frame octets from the lapd transmitter to the lapd receiver (of another uni chip) at a data rate of 64 kbps (1 byte per e3 frame). if the user opts not to use the nr byte to ?transport? these lapd message frames, then the transmit e3 framer will read in the contents of the ?tx nr byte? register (address = 2bh), and insert this value into the nr byte-field of each ?outbound? e3 frame. the receive e3 framer will read in the contents of the nr byte-field within each incoming e3 frame; and will write it into the ?rx nr byte? register. consequently, the user can determine the value of the nr byte, within the most recently received e3 frame, by reading the ?rx nr byte? register (address = 14h). 6.3.2.1.6 the general purpose communications channel (gc) byte the nr byte or the gc byte can be configured to transport lapd message frames from the lapd transmitter to the lapd receiver (of another uni chip) at a rate of 64 kbps (1 byte per e3 frame). if the user opts not to use the gc byte to ?transport? these lapd message frames, then the transmit e3 framer will table 21. a listing of the various payload type values and their corresponding meanings payload type value meaning 000 unequipped 001 equipped 010 atm 011 sdh tu-12s
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 188 read in the contents of the ?tx gc byte? register (address = 29h), and insert this value into the gc byte-field of each ?outbound? e3 frame. the receive e3 framer will read in the contents of the gc byte-field, within each incoming e3 frame, and will write it into the ?rx gc byte? register. consequently, the user can determine the value of the gc byte, within the most recently received e3 frame, by reading the ?rx gc byte register? (address = 15h). 6.3.3 functional description of the transmit e3 framer block the transmit e3 framer receives atm cells from the transmit cell processor, and inserts this data into the payload portion of each ?outbound? e3 frame. the transmit e3 framer proceeds to generate the oh bytes, and include these bytes with the e3 payload bytes in order to form the complete e3 frame. the transmit e3 framer will then encode this e3 frame data into a unipolar format (for transmission over optical fiber) or in a bipolar format (ami or hdb3 line code) for transmission over a transformer-coupled copper medium, to a far away e3 receiver terminal via an liu ic. the transmit e3 framer also provides a serial input port to allow the user to insert his/her own overhead (oh) bytes into the outbound e3 frames. finally, the transmit e3 framer allows the user to insert errors into some of the oh bytes and to transmit various alarm conditions upon software control in order to support equipment testing as well as transmitting the appropriate alarm signals as conditions warrant. figure 32 presents a simple illustration of the transmit e3 framer block, along with the associated external pins. figure 32. a simple illustration of the transmit e3 framer block and the associated external pins txpos txneg transmit e3 framer txframe txohclk txlineclk txaisen txframeref txinclk txohins txoh from transmitter cell processor to e3 line interface unit txohframe
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 189 figure 33 presents a functional block diagram of the transmit e3 framer block. figure 33. a functional block diagram of the transmit e3 framer block 6.3.3.1 the error monitor (em) byte calculator the purpose of the em byte is to support error detection in the transmission of the e3 frames between the ?near- end? transmit e3 framer and the ?far end? receive e3 framer. the transmit e3 framer will compute the bit- interleaved parity (bip-8) value for a given e3 frame, based upon the contents of the 537 octets, within that e3 frame. afterwards, the transmit e3 framer will insert the resulting bip-8 value, into the ?em? byte-field of the very next outbound e3 frame. for information on how the receive e3 framer processes the em byte, please see section 7.1.2.4. 6.3.3.2 far end block error (febe) the ?far-end block error? bit-field resides in bit 6, within the ma byte of each e3 frame, as depicted below. the purpose of the febe (far end block error) bit-field (within the ma byte) is two-fold. 3. it allows a terminal (which is transmitting e3 frames to a ?far-end? terminal) to determine whether or not the ?far-end? terminal is receiving its e3 frame data in an ?error-free? fashion. bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 ferf febe payload type payload dependent timing marker control & timing generator tx lapd block with 88 bytes of ram overhead generator external oh receiver with serial to parallel converter bip-8 calculator parallel to serial converter txe3 registers hdb3 encoder oh/ payload mux txoh sync to 8kref testmode rxframe 8kref rxlineclk txinclk synctorxtiming databus[7:0] hdb3 enable txpos txneg ais/los patterns bip8[7:0] txohclk clocktotxcp txlineclk txohframe txframe ramaddr[7:0] write addr_select controls from regs ais/los enable data bus[7:0] reg_select write read control_sig status_ind. txbytedata[7:0] from txcell processor oh/pl select oh position
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 190 4. it allows a terminal (which is receiving e3 frames from a ?far-end? terminal) to inform the ?far-end? terminal when it is receiving ?errored? e3 frames from that same ?far-end? terminal. the role of the febe bit-field is best presented in the practical example below. example consider a ?near-end? terminal that is communicating with a ?far-end? terminal. this ?near-end? terminal con- sists of the ?transmit e3 framer? and ?receive e3 framer? blocks within the XR-T7234 e3 uni ic; as depicted in figure 34. the ?transmit e3 framer? will generate and transmit e3 frames to the ?far-end? terminal. likewise, the ?receive e3 framer? will receive and process e3 frames, originating from the ?far-end? terminal. the ?near-end? receive e3 framer (e.g., the receive e3 framer on this particular chip) is going to verify the value of the em bytes, within the incoming e3 frames (from the ?far-end? terminal). if the ?near-end? receive e3 framer detects no errors in the incoming em bytes, then it will notify the ?far-end? terminal of this fact, by having the ?near end? transmit e3 framer, set the ?febe? bit (within the ma byte), within an ?outbound? e3 frame (which is destined for the ?far-end? terminal); to ?0?. this phenomenon is illustrated in figures 34 and 35, below. figure 34 illustrates the ?near-end? receive e3 framer receiving an ?error-free? e3 frame. in this figure, the locally computed em byte of ?5ah? matches that received from the ?far-end? terminal. figure 35 illustrates the subsequent action of the ?near-end? transmit e3 framer, which will transmit an e3 frame, with the febe bit-field set to ?0?; to the ?far-end? terminal. this signaling indicates that the ?near-end? receive e3 framer has received an ?error free? e3 frame from the ?far-end? terminal. figure 34. illustration of the ?near-end? receive e3 framer, receiving an e3 frame (from the ?far-end? terminal) with a correct em-byte. figure 35, illustration of the ?near-end? transmit e3 framer, transmitting an e3 frame (to the ?far-end? terminal) with the febe bit (within the ma byte-field) set to ?0?. conversely, if the ?near-end? receive e3 framer detects an error in the incoming em byte, then it will notify the ?far-end? terminal of this fact, by having the ?near-end? transmit e3 framer, set the ?febe? bit within an ?outbound? e3 frame (which is destined for the ?far-end? terminal); to ?1?. this phenomenon is illustrated in figures 36 and 37. figure 36 illustrates the ?near-end? receive e3 framer receiving an ?errored? e3 frame from the ?far-end? terminal. transmit e3 framer receive e3 framer near-end terminal far-end terminal em byte locally calculated em byte 5ah 5ah
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 191 in this figure, the ?near-end? receive e3 framer is receiving an e3 frame, with an em byte containing the value ?5ah?. this value does not match the ?locally computed? em byte value of ?5bh?. consequently, there is an error in this e3 frame. figure 37 illustrates the subsequent action of the ?near-end? transmit e3 framer, which will transmit an e3 frame, with the febe bit-field set to ?1?; to the ?far-end? terminal. this signaling indicates that the ?near-end? receive e3 framer has received an ?errored? e3 frame from the ?far-end? terminal. figure 35. illustration of the ?near-end? receive e3 framer, receiving an e3 frame (from the ?far-end? terminal) with an incorrect em-byte. figure 36. illustration of the ?near-end? transmit e3 framer, transmitting an e3 frame (to the ?far-end? terminal) with the febe bit (within the ma byte-field) set to ?1?. for information on how the receive e3 framer processes the febe bit-field, within each incoming e3 frame, please see section 7.1.2.6. transmit e3 framer receive e3 framer near-end terminal far-end terminal ma byte x0xxxxxx febe bit transmit e3 framer receive e3 framer near-end terminal far-end terminal em byte locally calculated em byte 5ah 5bh
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 192 manipulating the ?febe? bit-field the user can manipulate the state of the ?febe? bit-field, within an ?outbound? e3 frame by executing the following two-step procedure. 1. write a ?0? into bit 0 (marx), within the ?tx e3 configuration? register (address = 28h); as depicted below. this step will configure the transmit e3 framer to read in the contents of bit-field 6, within the ?tx ma byte? register; and insert it into the ?febe? bit-field of the ?outbound? e3 frame. 2. write the desired value for the ?febe? bit-field into bit 6 (febe) within the ?tx ma byte? register, as depicted below . 6.3.3.3 alarm generation the transmit e3 framer can be commanded to generate various types of alarm patterns, at will, upon software command. some of these alarms conditions, and the approaches that are used to invoke these alarms are presented below. 6.3.3.3.1 generating the ferf (far-end receive failure) indicator the transmit e3 framer will transmit a ?ferf? indication in response to the ?near-end? receive e3 framer detect- ing an ?los?, ais, or oof condition. the transmit e3 framer can also transmit a ?ferf? indication at the user?s will, under software command. generating the ferf indicator in response to ?adverse? receive conditions if the receive e3 framer detects an los, ais, or an oof condition in the e3 frame data that it is receiving from a ?far-end? terminal; then the receive e3 framer will notify this ?far-end? terminal of these problems by having the ?near-end? transmit e3 framer set the ?ferf? bit-field, within an ?outbound? e3 frame (which is destined for the ?far-end? terminal) to ?1?. conversely, if the receive e3 framer receives a ?normal? e3 frame, from the ?far-end? terminal; then the receive e3 framer will notify the ?far-end? terminal of this fact by having the ?near-end? transmit e3 framer set the ?ferf? bit-field, within an ?outbound? e3 frame (which is destined for the ?far-end? terminal) to ?0?. figure 38 through 41 illustrates this phenomenon. tx e3 configuration register (address = 28h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 auto re-transmit txlapdtype[1:0] dlinnr nodata link txais en txlos en marx r/w r/w r/w r/w r/w r/w r/w r/w 1 x x x x 0 1 0 tx ma byte register (address = 2ah) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 txma[7:0] ferf febe payload type payload dependent timing marker r/w r/w r/w r/w r/w r/w r/w r/w x x 0 1 0 x x x
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 193 figure 38 illustrates the ?near-end? receive e3 framer experiencing an los condition in the e3 frame data that it is receiving from the ?far-end? terminal. figure 39, illustrates the subsequent action of the ?near-end? transmit e3 framer. in this case, the transmit e3 framer will set the ?ferf? bit-field, in the outbound e3 frame (which is destined for the ?far-end? terminal) to ?1?. figure 37. illustration of the ?near-end? receive e3 framer experiencing an los condition figure 38. illustration of the ?near-end? transmit e3 framer, transmitting an e3 frame (to the ?far-end? terminal) with the ferf bit (within the ma byte-field) set to ?1?. transmit e3 framer receive e3 framer near-end terminal far-end terminal ma byte x1xxxxxx febe bit transmit e3 framer receive e3 framer near-end terminal far-end terminal
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 194 figure 39. illustrates the ?near-end? receive e3 framer receiving a ?normal? e3 frame from the ?far-end? terminal. figure 41 illustrates the subsequent action of the ?near-end? transmit e3 framer. in this case, the transmit e3 framer will set the ?ferf? bit-field, in the outbound e3 frame (which is destined for the ?far-end? terminal) to ?0?. figure 40. illustration of the ?near-end? receive e3 framer receiving a proper e3 signal from the ?far-end? terminal. transmit e3 framer receive e3 framer near-end terminal far-end terminal ma byte 1xxxxxxx ferf bit transmit e3 framer receive e3 framer near-end terminal far-end terminal
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 195 figure 41. illustration of the ?near-end? transmit e3 framer, transmitting an e3 frame (to the ?far-end? terminal) with the ferf bit (within the ma byte-field) set to ?0?. manipulating the ?ferf? bit-field the user (or local m p) can manipulate the state of the ?ferf? bit-field within an ?outbound? e3 frame, by executing the following two-step procedure. 1. write a ?0? into bit 0 (marx) within the ?tx e3 configuration? register (address = 28h); as depicted below. this step will configure the transmit e3 framer to read in the contents of bit 7, within the ?tx ma byte? register; and insert it into the ?ferf? bit-field of the ?outbound? e3 frame. 2. write the desired value for the ?ferf? bit into bit 7 (ferf) within the ?tx ma byte? register, as depicted below. tx e3 configuration register (address = 28h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 auto re- transmit txlapdtype[1:0] dlinnr nodata link txais en txlos en marx r/w r/w r/w r/w r/w r/w r/w r/w 1 x x x x 0 1 0 tx ma byte register (address = 2ah) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 transmit e3 framer receive e3 framer near-end terminal far-end terminal ma byte 0xxxxxxx ferf bit
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 196 6.3.3.3.2 generating the ais (alarm indication signal) condition pattern the transmit e3 framer can be commanded to generate an ais condition pattern, at the user?s will, upon software command. if the user writes a ?1? into bit 2 (txaisen) within the ?tx e3 framer configuration? register (address = 28h), as depicted below: then the transmit e3 framer will generate an all ?1s? pattern. the ?all ones? pattern will be interpreted by the ?far- end? receive e3 framer as the ais condition. if the user writes a ?0? into this bit-field then the transmit e3 framer will resume the transmission of the e3 frame oh and payload bytes. note: 1. because the payload portion of the e3 frame is being overwritten by this ?all one?s? pattern, no atm cell data will be transmitted to the ?far end? receive e3 framer, while this command is invoked. 2. the ?all one?s? pattern will also overwrite the frame alignment bytes, within each e3 frame. hence, command- ing the transmit e3 framer to generate an ?ais? pattern will cause the ?far-end? receive e3 framer to lose framing and declare an oof and lof conditions. 6.3.3.3.3 generating the los (loss of signal) condition the transmit e3 framer can generate a signal that simulates an los condition, at the user?s will, upon software command. if the user writes a ?1? into bit 1 (txlosen) within the tx e3 framer configuration register (address = 28h), as depicted below: txma[7:0] ferf febe payload type payload dependent timing marker r/w r/w r/w r/w r/w r/w r/w r/w 1 x 0 1 0 x x x tx e3 framer configuration register (address = 28h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 auto re- transmit txlapdtype[1:0] dlinnr nodata link txais en txlos en marx r/w r/w r/w r/w r/w r/w r/w r/w 1 x x x x 1 0 x tx e3 framer configuration register (address = 28h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 tx ma byte register (address = 2ah)
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 197 then the transmit e3 framer will generate an all ?0s? pattern. this ?all zeros? pattern will be interpreted by the ?far end? receive e3 framer as the los condition. if the user writes a ?0? into this bit-field, then the transmit e3 framer will resume the transmission of the e3 frame oh and payload bytes. note: 1. because the payload portion of the e3 frame is being overwritten by the ?all zero?s? pattern, no atm cell data will be transmitted to the ?far end? receive e3 framer, while this command is invoked. 2. the ?all zero?s? pattern will also overwrite the frame alignment bytes, within each e3 frame. hence, com- manding the transmit e3 framer to generate an ?los? pattern will cause the ?far-end? receive e3 framer to lose framing and declare an oof and lof conditions. 6.3.3.4 trail trace buffers the XR-T7234 e3 uni device contains 16 bytes worth of ?transmit? trail trace buffers, and 16 bytes worth of ?receive? trail trace buffers. the role of the ?transmit? trail trace buffers, is described below. the role of the ?receive? trail trace buffers are described in section 7.1.2.7. the XR-T7234 e3 uni device contains 16 ?transmit trail trace buffer registers (e.g., tx ttb-0 through tx ttb- 15). the purpose of these registers are to provide a 16-byte ?trail access point identifier? to the ?far-end? receiving terminal. the ?far-end? receiving terminal will use this information to verify that it is still receiving data from its intended transmitter. the specific use of these registers follows. for ?trail trace buffer message? purposes, the transmit e3 framer will group 16 consecutive e3 frames, into a ?trail trace buffer? super-frame. when the transmit e3 framer is generating the first e3 frame, within a ?trail trace buffer? super-frame, it will read in the contents of the ?tx ttb-0? register (address = 2ch) and insert this value into the tr byte-field of this very first ?outbound? e3 frame. when the transmit e3 framer is generating the very next e3 frame, (e.g., the second e3 frame, within a ?trail trace buffer? super-frame), it will read in the contents of the ?tx ttb-1? register (address = 2dh) and insert this value into the tr byte-field of this ?out- bound? e3 frame. as the transmit e3 framer is creating each subsequent e3 frame, within this ?trail trace buffer? super-frame, it will continue to increment to the very next ?transmit trail trace buffer? register. the transmit e3 framer will then read in the contents of this particular ?transmit trail trace? buffer register (e.g., tx ttb-n) and insert this value into the tr byte-field of the very next outbound e3 frame. after the transmit e3 framer has created the 16th e3 frame, within a given ?trail trace buffer? super-frame (e.g., it has read in the contents of the ?tx ttb-15? register, and has inserted this value into the tr-byte of the 16th e3 frame); it will begin to create a new ?trail trace buffer? super-frame, by reading the contents of the ?tx ttb-0? register, and repeating the above-mentioned procedure. the contents of the ?tx ttb-0? register will typically be of the form [1, c6, c5, c4, c3, c2, c1, c0]. the ?1? in the msb (most significant bit) position of this byte, is used to designate that this octet is the ?frame start marker? (e.g., is the first of the 16 tr bytes, within a ?trail trace buffer? super-frame). the remaining trail trace buffer registers (tx ttb-1 through tx ttb-15) will typically contain a ?0? in their msb (most significant bit) positions. the remaining bits within the ?tx ttb-0? register; c6 through c0 are the crc-7 bits calculated over the contents of all 16 tr bytes, within the previous ?trail trace buffer? super-frame. the contents of the remain- ing ?transmit trail trace buffer? registers (e.g., tx ttb-1 through tx ttb-15) will typically contain the 15 ascii characters required for the e.164 numbering format. note: 1. the XR-T7234 e3 uni will not compute the crc-7 value, to be written into the tx ttb-0 register. the user?s system must compute this value prior to writing it into the tx ttb-0 register. auto re- transmit txlapdtype[1:0] dlinnr nodata link txais en txlos en marx r/w r/w r/w r/w r/w r/w r/w r/w 1 x x x x 0 1 x tx e3 framer configuration register (address = 28h)
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 198 2. the user, when writing data into the tx ttb registers, must take care to insure that only the tx ttb-0 register contains an octet with a ?1? in the msb (most significant bit) position. all remaining tx ttb registers (e.g., tx ttb-1 through tx ttb-15) must contain octets with a ?0? in the msb position. the reason for this ?cautionary? note is presented in section 7.1.2.7 6.3.3.5 the lapd transmitter the lapd transmitter allows the user to transmit path maintenance data link (pmdl) messages to the ?far-end? receiver via the ?outbound? e3 frames. the user can configure the transmit e3 framer to transport the octets, comprising this outbound pmdl message, via the nr or the gc byte-fields, within each outbound e3 frame. fur- ther, the user can configure the lapd transmitter to transmit a lapd message frame (containing a pmdl mes- sage) only once or repeatedly at one-second intervals. 6.3.3.5.1 the lapd message frame the on-chip lapd transmitter supports both the 76 byte and 82 byte length message formats, and the uni allo- cates 88 bytes of on-chip ram (e.g., the ?transmit lapd message? buffer) to store the pmdl message to be trans- mitted. prior to transmission to the ?far-end? terminal, the lapd transmitter will encapsulate the pmdl message (e.g., the data which has been written into the transmit lapd message buffer) into an itu-t q.921 compliant (or lapd) message frame. figure 42 presents the byte format of the resulting lapd message frame. flag sequence (8 bits) sapi (6-bits) c/r ea tei (7 bits) ea control (8-bits) 76 or 82 bytes of information (payload) fcs - msb fcs - lsb flag sequence (8-bits)
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 199 figure 42. lapd message frame format where: flag sequence = 7eh sapi + cr + ea = 3ch or 3eh tei + ea = 01h control = 03h the following sections defines each of these bit/byte-fields within the lapd message frame format. flag sequence byte the flag sequence byte is assigned the value 7eh, and is used to denote the boundaries of the lapd message frame. sapi?service access point identifier the sapi bit-fields are assigned the value of ?001111b? or 15 10 . tei?terminal endpoint identifier the tei bit-fields are assigned the value of 00h. the tei field is used in n-isdn systems to identify a terminal out of multiple possible terminal. however, since the uni transmits data in a point-to-point manner, the tei value is unimportant. control the control identifies the type of frame being tra nsmitted. there are three general types of frame formats: informa- tion, supervisory, and unnumbered. the uni assigned the control byte the value 03h. hence, the uni will be transmitting and receiving unnumbered lapd message frames. information payload the ?information payload? is the 76 bytes or 82 bytes of data (e.g., the pmdl message) that the user has written into the on-chip ?transmit lapd message? buffer (which is located at addresses 86h through ddh).
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 200 it is important to note that the user must write in a specific octet value into the first byte position within the transmit lapd message buffer (located at address = 86h, within the uni). the value of this octet depends upon the type of lapd message frame/pmdl message that the user wishes to transmit. table 22 presents a list of the various types of lapd message frames/pmdl messages that are supported by the XR-T7234 e3 uni device; and the corresponding octet value that the user must write into the first octet position within the ?transmit lapd message buffer. frame check sequence bytes the 16 bit fcs (frame check sequence) is calculated over the lapd message header bytes (e.g., the flag sequence, sapi, tei, and control bytes) and the information payload bytes, by using the crc-16 polynomial, x 16 + x 12 + x 5 + 1. afterwards, this fcs value is inserted into the two-octet ?fcs value? position, within the lapd message frame. 6.3.3.5.2 the operation of the lapd transmitter if the user wishes to transmit a pmdl message via the lapd transmitter, he/she must perform the following steps. 1. specify the type of lapd message frame to be transmitted (within the transmit lapd message buffer). 2. write the pmdl message into the remaining portion of the transmit lapd message buffer. 3. specify the type of lapd message frame to be transmitted (via register settings). 4. specify which byte-field (within the e3 frame) that the lapd message frame is to be transported on. 5. specify whether the lapd transmitter should transmit this lapd message frame only once, or an indefi- nite number of times at one-second intervals. 6. enable the lapd transmitter 7. (initiate the transmission) each of these steps are discussed in detail below. 1. specify the type of lapd message frame to be transmitted (within the transmit lapd message buffer) the user must write in a specific octet value into the first octet position within the transmit lapd message buffer (e.g., at address location 86h within the uni). this octet is referred to as the ?lapd message frame id? octet. the value of this octet must correspond to the type of lapd message frame, he/she wishes to transmit. this octet will ultimately be used by the ?far-end? lapd receiver, in order to help it identify the type of lapd message frame that it is receiving. table 22 lists these octets and the corresponding lapd message types. 2. write the pmdl message into the remaining part of the transmit lapd message buffer. the user must now write in his/her pmdl message into the remaining portion of the transmit lapd message buffer (e.g., addresses 87h through 135h within the uni). 3. specifying the type of lapd message to be transmitted (via register settings) once again, the user must specify which type of lapd message he/she wishes to send. however, in this step the user is informing the lapd transmitter which type of message that he/she wishes to transmit. as men- tioned earlier, the user can transmit one of four different types of lapd messages. he/she can accomplish this by writing the appropriate data to bits 1 and 2 of the tx e3 configuration register (address = 28h). the bit-for- table 22. the lapd message type and the corresponding value of the first byte, to be written into the ?transmit lapd message? buffer lapd message frame type value of first byte to be written into the transmit lapd message buffer (86h in the uni address space) pmdl message size cl path identification 38h 76 bytes idle signal identification 34h 76 bytes test signal identification 32h 76 bytes itu-t path identification 3fh 82 bytes
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 201 mat of this register is presented below. the relationship between the contents of bit-fields 5 and 6, within the ?tx e3 configuration? register, and the lapd message type follows. note: this register configuration is used by the ?near-end? lapd transmitter, in order to determine how to encap- sulate the pmdl message into a lapd message frame. therefore, this message type selected must correspond with the value of the first byte written into the ?transmit lapd message? buffer, as presented in table 22. 4. specifying which byte-field (within the e3 frame) that the lapd message frame octets are to be transported on. the transmit e3 framer allows the user to transport the lapd message frame octets via either the nr byte or via the gc byte-field, within each outbound e3 frame. the user makes this selection by writing the appropriate value to bit-field 4 (dlinnr), within the ?tx e3 configuration? register, as depicted below. if the user writes a ?0? into this bit-field, then the lapd transmitter will transmit the comprising octets of the outbound lapd message frame via the gc byte-field, within each outbound e3 frame. additionally, the transmit e3 framer will insert the contents of the ?tx nr byte? register (address = 2bh) into the nr byte of each outbound e3 frame. conversely, if the user writes a ?1? into this bit-field, then the lapd transmitter will transmit the outbound lapd message frame octets via the nr byte-field, within each outbound e3 frame. additionally, the transmit e3 framer will insert the contents of the ?tx gc byte? register (address = 29h) into the gc byte of each outbound e3 frame. 5. specify whether the lapd transmitter should transmit the lapd message frame only once, or an indefinite number of times at one-second intervals. the transmit e3 framer allows the user to configure the lapd transmitter to transmit this lapd message frame only once, or an indefinite number of times at one-second intervals. the user implements this configuration by writing tx e3 configuration register (address = 28h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 auto re-transmit txlapdtype[1:0] dlinnr no datalink txais en txlos en marx r/w r/w r/w r/w r/w r/w r/w r/w table 23. relationship between txlapdtype[1:0] and the lapd message type/size txlapd type[1:0] lapd message type/size 00 lapd message type is ?test signal? type. the size of this message is 76 bytes 01 lapd message type is ?idle signal identification? type. the size of this message is 76 bytes. 10 lapd message type is ?cl path identification type?. the size of this message is 76 bytes 11 lapd message type is ?itu path identification type?. the size of this message is 82 bytes. tx e3 configuration register (address = 28h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 auto re-transmit txlapdtype[1:0] dlinnr no datalink txais en txlos en marx r/w r/w r/w r/w r/w r/w r/w r/w
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 202 the appropriate value into bit 7 (auto retransmit) within the ?tx e3 configuration? register; as depicted below. if the user writes a ?1? into this bit-field, then the lapd transmitter will transmit the lapd message frame repeat- edly at one-second intervals until the lapd transmitter is disabled. if the user writes a ?0? into this bit-field, then the lapd transmitter will transmit the lapd message frame only once. afterwards, the lapd transmitter will halt its transmission until the user invokes the ?transmit lapd message frame? command, once again. 6. enable the lapd transmitter prior to the transmission of any data via the lapd transmitter, the user must enable the lapd transmitter. he/ she can accomplish this by writing a ?0? into bit 3 (no datalink) of the tx e3 configuration register, as depicted below. if the user writes a ?0? into this bit-field, then the lapd transmitter will be enabled, and the lapd transmitter will begin to transmit a continuous stream of flag sequence octets (7eh), via either the gc or the nr byte-field of each outbound e3 frame (depending upon the user?s setting for bit 4 of this register). if the user writes a ?1? into this bit-field, then the lapd transmitter will be disabled. the transmit e3 framer will then insert the contents of the tx gc byte register, into the gc byte-field, for each outbound e3 frame. like- wise, the transmit e3 framer will also insert the contents of the tx nr byte register, into the nr byte, for each outbound e3 frame. no transmission of data from the lapd transmitter will occur. 7. initiate the transmission at this point, the user should have written the pmdl message into the on-chip transmit lapd message buffer. he/she should have specified the type of lapd message that he/she wishes to transmit. third, he/she should have specified whether the lapd transmitter will transport the lapd message frame octets via the gc byte- field or via the nr byte-field of each outbound e3 frame. finally, the user should have enabled the lapd trans- mitter. the only thing remaining to do is to initiate the transmission of this message. the user initiates this pro- cess by writing a ?1? to bit 3 (txdl start) within the tx e3 lapd status/interrupt register (address = 3fh); as depicted below. a ?0? to ?1? transition of bit 3 (txdl start) in this register, initiates the transmission of lapd message frames. at this point, the lapd transmitter will begin to search through the pmdl message, which is residing within tx e3 configuration register (address = 28h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 auto re-transmit txlapdtype[1:0] dlinnr no datalink txais en txlos en marx r/w r/w r/w r/w r/w r/w r/w r/w tx e3 configuration register (address = 28h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 auto re-transmit txlapdtype[1:0] dlinnr no datalink txais en txlos en marx r/w r/w r/w r/w r/w r/w r/w r/w tx e3 lapd status/interrupt register (address = 3fh) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused txdl start txdl busy txlapd interrupt enable txlapd interrupt status ro ro ro ro r/w r/w r/w r/w
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 203 the ?transmit lapd message? buffer. if the lapd transmitter finds any string of five (5) consecutive ?1s? in the pmdl message; then the lapd transmitter will insert a ?0? immediately following these strings of consecutive ?1s?. this procedure is known as ?stuffing?. the purpose of ?pmdl message? stuffing is to insure that the user?s pmdl message does not contain strings of data that mimic the ?flag sequence? byte (e.g., six consecutive ?1s?) or the ?abort sequence? (e.g., seven consecutive ?1s?). afterwards, the lapd transmitter will begin to encapsulate the pmdl message, residing in the transmit lapd message buffer, into a lapd message frame. finally, the lapd transmitter will fragment the ?outbound? lapd message frame into octets; and will begin to transport these octets via the gc or the nr byte-fields (depending upon the user?s selection) of each outbound e3 frame. while the lapd transmitter is transmitting this lapd message frame, the ?txdl busy? (bit 2) bit, within the tx e3 lapd status/interrupt register, will be set to ?1?; as depicted below. this bit-field allows the user to ?poll? the status of the lapd transmitter. once the lapd transmitter has completed the transmission of the lapd message frame, this bit-field will toggle back to ?0?. the user can configure the lapd transmitter to interrupt the local m c/ m p upon completion of transmission of the lapd message frame, by setting bit-field ?1? (txlapd interrupt enable) of the ?tx e3 lapd status/interrupt? register to ?1?, as depicted below. the purpose of this interrupt is to let the local m c/ m p know that the lapd transmitter is available and ready to transmit a lapd message frame with a new pmdl message. bit 0 (txlapd interrupt status) within the tx e3 lapd interrupt/status register will reflect the status for the lapd transmitter interrupt. note: this bit-field will be reset upon reading this register. tx e3 lapd status/interrupt register (address = 3fh) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused txdl start txdl busy txlapd interrupt enable txlapd interrupt status ro ro ro ro r/w r/w r/w r/w 0 0 0 0 1 1 x x tx e3 lapd status/interrupt register (address = 3fh) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused txdl start txdl busy txlapd interrupt enable txlapd interrupt status ro ro ro ro r/w r/w r/w r/w 0 0 0 0 0 0 1 x
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 204 summary of operating the lapd transmitter once the user has invoked the ?txdl start? command, the lapd transmitter will do the following. ? generate the four octets of the lapd message frame header (e.g., flag sequence, sapi, tei, control, etc.) and insert it into the header octet positions within the lapd message frame. ? it will read in the contents of the ?transmit lapd message? buffer (e.g., the pmdl message data) and insert it into the ?information payload? portion of the lapd message frame. ? compute the 16-bit ?frame check sum? (fcs) of the lapd message frame (e.g., of the lapd message header and the pmdl message data) and insert this value into the fcs value octet positions within the lapd message frame. ? append a ?trailer? flag sequence octet to the end of the lapd message frame (following the 16 bit fcs value). ? fragment the resulting lapd message frame into octets; and begin inserting these octets, into either the gc or nr byte-field of the outbound e3 frame (depending upon the user?s selection). ? complete the transmission of the frame overhead, information payload, fcs value, and trailing flag sequence octets via the transmit e3 framer. once the lapd transmitter has completed its transmission of the lapd message frame, the uni will generate an interrupt to the local m c/ m p (if enabled). afterwards, the lapd transmitter will either halt its transmission of lapd message frames or will proceed to retransmit the lapd message frame, repeatedly at one-second intervals. in between these transmission of the lapd message frame, the lapd transmitter will be sending an continuous stream of ?flag sequence? bytes. the lapd transmitter will continue this behavior until the user has disabled the lapd transmitter by writing a ?1? into bit 3 (no datalink) within the tx e3 configuration register. note: in order to prevent the user?s data (the pmdl message within the lapd message frame) from mimicking the ?flag sequence? byte or an abort sequence, the lapd transmitter will search through the pmdl message data and insert a ?0? into this data, immediately following the detection of five (5) consecutive ?1s? (this ?stuffing? occurs while the pmdl message data is being read in from the ?transmit lapd message buffer? and is being encapsu- lated into a lapd message frame. the ?far-end? lapd receiver (see section 7.1.2.5) will have the responsibility of checking the ?newly received? pmdl messages for a string of 5 consecutive ?1s? and removing the subsequent ?0? from the payload portion of the incoming lapd message. figures 43 and 44 presents two flow chart diagrams. figure 43 depicts the procedure (in ?white boxes?) that the user should use in order to transmit a pmdl message via the lapd transmitter, when the lapd transmitter is config- ured to ?retransmit? the lapd message frame, repeatedly at one second intervals. this figure also indicates (via
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 205 the ?shaded? boxes) what the lapd transmitter circuitry will do before and during message transmission. figure 43. flow chart depicting how to use the lapd transmitter (lapd transmitter is configured to re-transmit the lapd message frame repeatedly at one-second intervals) figure 44 presents the procedure (in ?white boxes?) that the user should use in order to transmit a pmdl message via the lapd transmitter, when the lapd transmitter is configured to transmit the lapd message frame only start write the ?lapd message frame identification? octet into the first octet position within the ?transmit lapd message? buffer (address = 86h). write the pmdl message into the remaining portion of the ?transmit lapd message? buffer (from 87h to ddh). specify the type/size of the lapd message frame to be transmitted. write in the appropriate value into bits 5 and 6 within the tx e3 configuration register. enable the lapd transmitter. initiate the lapd message frame transmission. specify whether the ?outbound? lapd message frame is to be transported via the gc or the nr byte-fields, within each ?outbound? e3 frame. lapd transmitter will generate a continuous string of ?flag sequence? bytes. these bytes will be transported via either the gc or the nr byte field (depending upon user?s selection). lapd transmitter will ?stuff? the contents of the pmdl message (residing within the ?transmit lapd message? buffer). lapd transmitter will read out ?stuff? pmdl message and encapsulate it into a lapd message frame. lapd transmitter will compute and insert the fcs value, into the lapd message frame. lapd transmitter will fragment lapd message frame into ?octets? and begin to insert these octets into the gc or nr byte-field (depending upon user?s selection) into each ?outbound? e3 frame. complete transmission of lapd message frame. generate ?completion of transmission of lapd message frame interrupt. wait one second. generate a continuous string of flag sequence bytes. configure the lapd transmitter to repeat transmissions of the lapd message frame at one-second intervals.
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 206 once, and then halt transmission. figure 44. flow chart depicting how to use the lapd transmitter (lapd transmitter is configured to transmit the lapd message frame only once, and then halt) the mechanics of transmitting new lapd message, if the lapd transmitter has been configured to retransmit the lapd message frame, repeatedly at one-second intervals if the lapd transmitter has been configured to retransmit the lapd message repeatedly at one-second intervals, then it will do the following at one-second intervals. ? ?stuff? the pmdl message. ? read in the ?stuffed? pmdl message from the ?transmit lapd message? buffer. ? encapsulate this ?stuffed? pmdl message into a lapd message frame. ? transmit this lapd message frame to the ?far-end? terminal. if the user wishes to transmit another (e.g., a different) pmdl message to the ?far end? lapd receiver, he/she will have to write this ?new? message into the ?transmit lapd message? buffer, via the microprocessor interface sec- tion of the uni. however, the user must take care when writing in this new pmdl message. if he/she writes this generate ?completion of transmission of lapd message frame interrupt. start write the ?lapd message frame identification? octet into the first octet position within the ?transmit lapd message? buffer (address = 86h). write the pmdl message into the remaining portion of the ?transmit lapd message? buffer (from 87h to ddh). specify the type/size of the lapd message frame to be transmitted. write in the appropriate value into bits 5 and 6 within the tx e3 configuration register. enable the lapd transmitter. initiate the lapd message frame transmission. specify whether the ?outbound? lapd message frame is to be transported via the gc or the nr byte-fields, within each ?outbound? e3 frame. lapd transmitter will generate a continuous string of ?flag sequence? bytes. these bytes will be transported via either the gc or the nr byte field (depending upon user?s selection). lapd transmitter will ?stuff? the contents of the pmdl message (residing within the ?transmit lapd message? buffer). lapd transmitter will read out ?stuff? pmdl message and encapsulate it into a lapd message frame. lapd transmitter will compute and insert the fcs value, into the lapd message frame. lapd transmitter will fragment lapd message frame into ?octets? and begin to insert these octets into the gc or nr byte-field (depending upon user?s selection) into each ?outbound? e3 frame. complete transmission of lapd message frame. halt transmission for an ?indefinite period. wait until the user initiates ?lapd message frame transmission? again. configure the lapd transmitter to transmit lapd message frame only once.
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 207 message into the ?transmit lapd message? buffer at the ?wrong time? (with respect to these ?one-second? lapd message frame transmissions), the user?s action could interfere with these transmissions; thereby caus- ing the lapd transmitter to transmit a ?corrupted? message to the ?far-end? lapd receiver. in order to avoid this problem, while writing the new message into the ?transmit lapd message? buffer, the user should do the following. 1. configure the uni to automatically reset activated interrupts the user can do this by writing a ?1? into bit 5 of the ?uni i/o control? register, as depicted below. this action will prevent the lapd transmitter from generating its own ?one-second? interrupts. 2. enable the ?one-second? interrupt this can be done by writing a ?1? into bit 6 of the ?uni interrupt enable? register, as depicted below. 3. write the new message into the ?transmit lapd message? buffer immediately after the occurrence of the ?one-second? interrupt by timing the writes to the ?transmit lapd message? buffer to occur immediately after the occurrence of the ?one second? interrupt, the user avoids conflicting with the ?one-second? transmission of the lapd message frame, and will transmit the correct (uncorrupted) pmdl message to the ?far end? lapd receiver. 6.3.3.6 timing/framing reference for the transmit e3 framer block the transmit e3 framer will generate and transmit e3 frame data, based upon one of three different timing or framing sources: ? receive e3 framer timing ? txinclk input signal ? txframeref input signal the user can select which one of these three timing or framing source signals to use as the reference for the transmit e3 framer, by writing to bits 0 and 1 (timrefsel[1, 0]) within the uni operating mode register uni i/o control register, (address = 01h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 loc rx loc tx inten reset ami/ hdb3* unipolar/ bipolar* txline clk inv rxline clk inv reframe ro ro r/w r/w r/w r/w r/w r/w 0 0 1 0 0 0 0 0 uni interrupt enable register (address = 04h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused one sec interrupt enable tx e3 framer interrupt enable rx e3 framer interrupt enable tx cp interrupt enable rx cp interrupt enable tx utopia interrupt enable rx utopia interrupt enable ro r/w r/w r/w r/w r/w r/w r/w 0 1 0 0 0 0 0 0
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 208 (address = 00h); as depicted below. the following table lists the values of bits 0 and 1 and the resulting timing source for the transmit e3 framer block. each of these ?potential? timing and framing sources for the transmit e3 framer are discussed in greater detail below. 6.3.3.6.1 rxlineclk?receive e3 framer timing in this mode, the transmit e3 framer timing is based upon the recovered clock input signal, rxlineclk, obtained by the receive e3 framer. e3 framing (e.g., when the transmit e3 framer begins to create a new frame) will be asynchronous with respect to any external timing signals. this mode is convenient from the stand-point that it requires no external timing sources (to either the txframeref or txinclk pins). however, this configuration has one drawback: if the receive e3 framer block experiences an los condition, or somehow loses the recovered clock signal, then the transmit e3 framer block will essentially have no timing source. therefore, in this configuration, the operation of the transmit e3 framer block is dependent upon the actions of the ?near-end? receive e3 framer block and its incoming e3 data-stream signal. 6.3.3.6.2 txinclk input signal in this mode, the transmit e3 framer block will use the clock signal that is input at the txinclk pin, as the tim- ing reference. e3 framing (e.g., when the transmit e3 framer begins to create a new frame) will be asynchro- nous with respect to any external timing signals. if the user selects this mode, then he/she must insure that a high quality 34.368 mhz clock signal is applied at this input. the advantage of using this timing signal as the reference for the transmit e3 framer, over the rxlineclk sig- nal; is that an los condition (or a loss of clock recovery event with the incoming e3 line signal) does not adversely affect the transmit e3 framer?s operation. 6.3.3.6.3 txframeref input signal in this mode, the transmit e3 framer block will use the input signal, at the txframeref input pin as the ?fram- ing reference?. in other words, a rising edge at this input pin will cause the transmit e3 framer to begin its cre- ation of anew e3 frame. consequently, if the user selects this input signal as the framing reference signal, he/ she must supply a 8 khz clock signal to this input pin. uni operating mode register: (address = 00h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused disable loc intlos enable reset by reg cell loop back line loop back timrefsel[1, 0] ro r/w r/w r/w r/w r/w r/w table 24. the relationship between timrefsel[1:0] (e.g., bits 1 and 0 of the uni operating mode register), and the resulting timing/framing source for the transmit e3 framer block timrefsel [1:0] transmit e3 framer timing/frame source 0 0 txinclk input signal. framing is asynchronous upon ?power on?. 0 1 txframeref input signal. 1 0 rxlineclk input signal?the recovered clock signal from the incoming (received) e3 line signal. 1 1 txinclk input signal. framing is asynchronous upon ?power on?.
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 209 6.3.3.7 interfacing the transmit e3 framer to the line the XR-T7234 e3 atm uni is a digital device that takes atm cell data from an atm layer processor, processes this cell data and ultimately maps this information into the payload portion of an outbound e3 frame. in most applications, the user will transmit this e3 frame data to the ?far-end? terminal over a ?transformer-coupled? cop- per medium (e.g., coaxial cable) or over optical fiber. if the user wishes to transmit the e3 frame data over coax- ial cable, then he/she must interface the uni device to a line interface unit (liu) ic. an liu is a device that has sufficient drive capability, along with the necessary pulse-shaping circuitry to be able to transmit a signal through the transmission medium in a manner that it can be reliably received by the ?far-end? receiver. figure 45 presents a circuit schematic depicting the uni interfacing to an liu (xr-t7296 e3 transmit liu). if the user wishes to transmit the e3 frame data over optical fiber, then he/she must interface the uni to an ?elec- trical- to-optical? converter device. figure 45. schematic of the XR-T7234 e3 uni interfacing to the xr-t7295e and xr-t7296 e3 line interface unit devices. 6.3.3.7.1 line interface output mode the uni device can be configured to operate in one of two ?line interface? output modes. ? unipolar ? bipolar each of these ?line interface? output modes are described below. 5v t1 pe 65966 t2 pe 65966 r1 39 r2 39 r3 39 r4 270 r6 36 r5 270 r7 36 c2 0.01uf c1 0.1uf u2 xr-t7296 ds3, sts-1/e3 4 encodis 11 decodis 12 tndata 8 tpdata 7 tclk 9 rclko 17 rneg 15 rpos 16 rloop 2 taos 5 lloop 3 dmo 18 txlev 25 ttip 23 tring 22 mtip 20 mring 19 rclk 1 rpdata 27 rndata 28 u? XR-T7234 txneg 111 txpos 109 txlineclk 112 rxlineclk 99 rxneg 98 rxpos 97 txaddr0 147 txaddr1 149 txaddr2 150 txaddr3 148 txaddr4 146 txdata15 144 txdata14 142 txdata13 140 txdata12 138 txdata11 134 txdata10 132 txdata9 130 txdata8 128 txdata7 143 txdata6 141 txdata5 139 txdata4 137 txdata3 135 txdata2 133 txdata1 131 txdata0 129 rxdata0 70 rxdata1 68 rxdata2 64 rxdata3 62 rxdata4 60 rxdata5 58 rxdata6 56 rxdata7 54 rxdata8 69 rxdata9 67 rxdata10 65 rxdata11 63 rxdata12 61 rxdata13 57 rxdata14 55 rxdata15 53 rxaddr0 79 txclav 126 txsoc 124 txprty 125 txclk 151 txenb 123 rxclav 76 rxsoc 72 rxprty 74 rxclk 50 rxenb 81 rxaddr1 80 rxaddr2 77 rxaddr3 75 rxaddr4 73 encodis 22 rloop 26 lloop 28 reqb 12 rlos 86 rlol 8 taos 2 txlev 24 dmo 6 u? xr-t7295e rlos 7 rlol 8 lpf1 4 lpf2 5 exclk 13 rndata 12 rpdata 16 rclk 14 rin 2 reqb 18 ttip tring 34.386 mhz rtip rring txdata[15:0] txaddr[4:0] rxaddr[4:0] rxdata[15:0] txsoc txprty 50mhz txenb 50mhz rxenb txclav rxclav rxsoc rxprty
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 210 6.3.3.7.1.1 the unipolar mode the transmit e3 framer can transmit data to the liu ic or other external circuitry via two different output modes: unipolar or bipolar. if the user selects unipolar (or single-rail) mode, then the contents of the e3 frame is output via the txpos pin in a nrz (non-return-to-zero) format to external circuitry. the txneg pin will only be used to denote the frame boundaries. txneg will pulse ?high? for one bit-period, at the start of each new e3 frame, and will remain ?low? for the remainder of the frame period. figure 46 presents an illustration of the txpos and txneg sig- nals during data transmission while the uni is operating in the unipolar mode. this mode is sometimes referred to as the ?single rail? mode because the data pulses only exist in one polarity: positive. figure 46. the behavior of txpos and txneg signals during data transmission while the uni is operating in the unipolar mode note: the user is advised not to operate the uni in the unipolar mode if he/she wishes to transmit the e3 frame data to a ?far-end? e3 terminal over some transformer-coupled copper medium. the user should, instead, use one of the bipolar-mode line codes for this application. the unipolar mode can be used to drive the line signals through optical fiber. in this case, the txpos output would be applied to an led at the electrical/optical interface circuitry. the user can configure the uni to operate in the unipolar mode, by writing a ?1? to bit 3 (unipolar/bipolar*) within the uni i/o control register (address = 01h), as shown below. 6.3.3.7.1.2 the bipolar mode when the uni is operating in the bipolar (or dual-rail) mode, then the contents of the e3 frame data is output via both the txpos and txneg pins. if the user chooses the bipolar mode, then he/she can transmit the e3 line signal to the ?far-end? receiver via one of two different line codes: alternate mark inversion (ami) or high density bipolar-3 (hdb3). each one of these line codes will be discussed below. the bipolar mode is sometimes referred to as the ?dual-rail? uni i/o control register (address = 01h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 loc rx loc tx interrupt enable reset ami/ hdb3* unipolar/ bipolar* txline clk inv rxline clk inv reframe ro ro r/w r/w r/w r/w r/w r/w 0 0 x x 1 x x 0 txpos txneg txlineclk data frame boundary 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 211 mode because the data pulses occur in two polarities: positive and negative. it is important to note that the bipolar mode is the ?mode of choice?, if the user is trying to transmit the e3 frame data over transformer-coupled coaxial cable. this is because the ?bipolar? line codes introduce no dc component into the line signal. hence, dc distortion is minimized. the role of the txpos, txneg and txlineclk output pins, for the bipolar mode are discussed below. txpos?transmit positive polarity pulse: the uni device will assert this output to the liu ic when it desires for the liu to generate and transmit a ?positive polarity? pulse to the ?far-end? receiver. txneg?transmit negative polarity pulse: the uni device will assert this output to the liu ic when it desires for the liu to generate and transmit a ?negative polarity? pulse to the ?far-end? receiver. txlineclk?transmit line clock: the liu ic uses this signal, from the uni, to sample the state of its txpos and txneg inputs. the results of this sampling dictates the type of pulse (positive polarity, zero, or negative polarity) that it will generate and transmit to the ?far-end? receive e3 framer. the user can configure the uni to operate in the bipolar mode, by writing a ?0? to bit 3 (unipolar/bipolar*) within the uni i/o control register (address = 01h), as shown below. 6.3.3.7.1.2.1 the ami line code ami or alternate mark inversion, means that consecutive ?one?s? pulses (or marks) will be of opposite polarity, with respect to each other. the line code involves the use of three different amplitude levels? ?+1?, ?0?, ?-1?. the ?+1? and ?-1? amplitude signals are used to represent one?s (or mark) pulses and the ?0? amplitude pulses (or the absence of a pulse) are used to represent zeros (or space) pulses. the general rule for ami is: if a given ?mark? pulse is of ?positive? polarity, then the very next ?mark? pulse will be of ?negative? polarity and vice versa. this alternating polarity relationship exists between two consecutive mark pulses, independent of the number of ?zeros? that may exist between these two pulses. the transmit e3 framer takes the binary stream of e3 frame data and outputs this data to the liu device, in the ami line code format via the txpos and txneg output pins. figure 47 presents an illustration of e3 frame data which is encoded into the ami line code. this figure illustrates this ami encoded e3 frame as it would appear at the txpos and txneg pins of the uni, as well as the output signal on the line. uni i/o control register (address = 01h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 loc rx loc tx interrupt enable reset ami/ hdb3* unipolar/ bipolar* txline clk inv rxline clk inv reframe ro ro r/w r/w r/w r/w r/w r/w 0 0 x x 0 x x 0
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 212 figure 47. illustration of ami line code as output by the transmit e3 framer, within the uni device. the user can configure the uni to operate with the ami line code by writing a ?1? to bit 4 (ami/hdb3*) within the ?uni i/o control? register, as depicted below. note: this bit-field is ignored if the uni is configured to operate in the unipolar mode. 6.3.3.7.1.2.2 the hdb3 line code the transmit e3 framer and the associated liu ic combine the e3 frame data and timing information (origi- nating from the txlineclk signal) into the e3 line signal that is transmitted to the ?far-end? terminal. the liu at the ?far-end? terminal has the task of recovering this data and timing information from the incoming pulses on the e3 line. most e3 liu devices, on the market today, contain clock and data recovery schemes that rely on the use of phase-locked- loop (pll) circuitry. the pll circuitry, within the liu, assists in the clock and data recov- ery process by ?locking? onto the transitions in the e3 line signal. therefore, these clock recovery schemes are vulnerable to the occurrence of a long stream of consecutive zeros (e.g., the absence of transitions in the line). hence, some approach is needed to insure that such a long string of consecutive zeros can never happen. one such technique that is used in the e3 transport medium is hdb3 encoding. in general, the hdb3 line code is very similar to the ami line code: with the exception of the case when a long string of consecutive zeros occurs on the line. in hdb3 line coding, any string of 4 consecutive zeros will be replaced with either a ?000v? or a ?b00v? where ?b? refers to a bipolar pulse (e.g., a pulse with a polarity that is compliant with the ami coding rule). and ?v? refers to a bipolar violation pulse (e.g., a pulse with a polarity that violates the alternating polarity scheme of ami). the decision between inserting an ?000v? or a ?b00v? is made to insure that an odd number of bipolar (b) pulses exist between any two bipolar violation (v) pulses. when the uni is configured to transmit e3 frame data in the hdb3 line code, the transmit e3 framer will take the e3 frame data and output it (onto the line) in the hdb3 format via the txpos and txneg output pins. figure 48 presents an illustration of the trans- mit e3 framer taking e3 frame data (in a binary data stream format) and converting it into the hdb3 encoded format. the ?hdb3-encoded? dual-rail data is then output to the liu via the txpos and txneg output pins. figure 48 also illustrates the resulting signal on the e3 line. ?uni i/o control? register (address = 01h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 loc rx loc tx interrupt enable reset ami/ hdb3* unipolar/ bipolar* txline clk inv rxline clk inv reframe ro ro r/w r/w r/w r/w r/w r/w 0 0 x 1 0 x x 0 data txpos txneg line signal 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 213 figure 48. illustration of two examples of hdb3 encoding note: figure 48 shows two examples of ?zero-suppression? due to the hdb3 line code. in the first example, a string of 4 consecutive zeros is replaced by a ?000v? pattern. in the second example, a string of 4 consecutive zeros is replaced by a ?b00v? pattern. the user can configure the uni to operate with the hdb3 line code by writing a ?0? to bit 4 (ami/hdb3*) within the ?uni i/o control? register, as depicted below. note: this bit-field is ignored if the uni is configured to operate in the unipolar mode. 6.3.3.7.2 txlineclk clock edge selection the uni allows the user to specify whether the e3 frame output data (via the txpos and txneg output pins) is to be updated on the rising or falling edges of the txlineclk signal. this selection is made by writing to bit 2 (txlineclk inv) within the ?uni i/o control? register, as depicted below. uni i/o control register (address = 01h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 loc rx loc tx interrupt enable reset ami/ hdb3* unipolar/ bipolar* txline clk inv rxline clk inv reframe ro ro r/w r/w r/w r/w r/w r/w 0 0 x 0 0 x x 0 uni i/o control register (address = 01h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 loc rx loc tx interrupt enable reset ami/ hdb3* unipolar/ bipolar* txline clk inv rxline clk inv reframe ro ro r/w r/w r/w r/w r/w r/w 0 0 x 1 0 x x 0 data txpos txneg 0 0 0 v line signal b 0 0 v 1 1 1 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 214 the following table relates the contents of this bit-field to the clock edge of txlineclk that updates the data on the txpos and txneg output pins. note: the user will typically make the selection based upon the ?set-up? and ?hold? time requirements of the ?transmit liu? ic. figure 49. waveform/timing relationship between txlineclk, txpos and txneg?- txpos and txneg are configured to be updated on the rising edge of txlineclk table 25. the relationship between the contents of bit 2 (txlineclk inv) within the uni i/o control register and the txlineclk clock edge that txpos and txneg outputs are updated on bit 2 result 0 rising edge: outputs on txpos and/or txneg are updated on the rising edge of txlineclk. see figure 49 for timing relationship between txlineclk, txpos and txneg signals, for this selection. 1 falling edge: outputs on txpos and/or txneg are updated on the falling edge of txlineclk. see figure 50 for timing relationship between txlineclk, txpos and txneg signals, for this selection. txlineclk txpos txneg t32 t30 t33
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 215 figure 50. waveform/timing relationship between txlineclk, txpos and txneg?txpos and txneg are configured to be updated on the falling edge of txlineclk 6.3.4 the transmit e3 framer serial output port the txoh serial input allows the user to insert his/her value(s) for the overhead (oh) bytes into the outbound e3 frames. the txoh serial input port is activated when the user asserts the txohins pin (e.g., toggles this input pin ?high?). once this serial port is activated, then the user is expected to serially apply his/her choices for the e3 oh bytes at the txoh input pin. the txohclk output pin functions as a clock that will sample and latch data at the txoh input pin on its rising edge. the frequency of this txohclk clock signal is approximately 448 khz. the txo- hframe output signal is provided to inform the user when the value for the msb (most significant bit) of the fa1 byte is expected. the txoh serial input port expects the user to apply his/her value for oh bytes in the order as presented in figure 31. the txoh serial input port also allows the user to selectively externally insert his/her value for the e3 oh data (e.g., allowing some of the oh bytes to be internally generated, while inserting his/her own values for the remaining overhead bits). this can be accomplished by ?keeping track? of the number of clock pulses occurring since the last assertion of the txohframe signal, and by asserting the txohins at the time the txoh serial input port would be expecting the ?oh byte(s) that the user wishes to be externally inserted?. the txohins input should be negated for the remainder of the e3 frame sampling period, so that these oh bytes will be internally generated. figure 51 presents a timing diagram that illustrates the behavior of the txoh serial interface signals during user txlineclk txpos txneg t31 t32 t33
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 216 input of the e3 oh bits. figure 51. timing diagram illustrating the behavior of the e3 oh byte serial input port, during user input of the oh bytes. 6.3.5 transmit e3 framer interrupts the transmit e3 framer block will generate an interrupt to the local m p/ m c upon the occurrence of one condition: ? completion of transmission of lapd message frame if this condition occurs, and if this particular condition has been enabled for interrupt generation, then when the local m p/ m c reads the uni interrupt status register (during the early stages of interrupt processing), as shown below; it txohframe txoh txohins txohclk t25 t26 t27 t29 t28 t24
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 217 should read 0x1xxxxxb (where the -b suffix denotes a binary expression, and the ?x? denotes a ?don?t care? value). at this point, the local m p/ m c has determined that the transmit e3 framer block is the source of the interrupt, and that the interrupt service routine should branch accordingly. since the transmit e3 framer only contains one possible source of interrupt, the interrupt service routine should branch to the ?tx e3 lapd status/inter- rupt? register (address = 3fh). the roles/functions of the bit-fields, within this register, that are relevant to interrupt processing are described below. this register has four (4) active bit-fields. however, only two of these bit-fields are relevant to interrupt process- ing. bit 0 is an interrupt status bit and bit 1 is an interrupt enable bit. bit 0?txlapd interrupt status this ?reset upon read? bit-field is asserted once the lapd transmitter has completed transmission of a lapd message frame to the ?far-end? receiver. additionally, the uni will notify the local m c/ m p of this fact by asserting the int* output pin to the local m c/ m p. the purpose of this interrupt is to alert the local m c/ m p that the lapd transmitter has completed the transmission of the lapd message frame, and that it is ready and avail- able to transmit another pmdl message. bit 1?txlapd interrupt enable this ?read/write? bit-field allows the user to enable/disable interrupts generated due to the completion of trans- mitting a lapd message frame to the ?far-end? receiver. the user can enable this interrupt by writing a ?1? to this bit-field. conversely, writing a ?0? into this bit-field disables this interrupt. uni interrupt status register (address = 05h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused one sec interrupt status tx e3 framer interrupt status rx e3 framer interrupt status tx cp interrupt status rx cp interrupt status tx utopia interrupt status rx utopia interrupt status ro rur ro ro ro ro ro ro 0 0 1 0 0 0 0 0 tx e3 lapd status/interrupt register (address = 3fh) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused txdl start txdl busy txlapd interrupt enable txlapd interrupt status ro ro ro ro r/w ro r/w rur 0 0 0 0 x x x x
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 219 7.0 the receive section the purpose of the receiver section of the XR-T7234 e3 atm uni device is to allow a local atm layer (or atm adaptation layer) processor to receive atm cell data from a remote piece of equipment via a public or leased e3 transport medium. the receive section of the e3 uni chip consists of the following functional blocks: ? receive e3 framer ? receive cell processor ? receive utopia interface the receive e3 framer will synchronize itself to this incoming e3 data stream (containing atm cells) via the rxpos, rxneg, and rxlineclk input pins, and proceed to ?strip off? and process the oh bytes of the e3 frame. once all of the oh bytes have been removed, the payload portion of the received e3 frame should consist of atm cells, which are subsequently sent on to the receive cell processor. the receive cell processor takes the ?unframed? stream of atm cell data and performs the following operations. ? cell delineation. ? hec byte verification it takes the first four octets of the cell (the header) and computes a hec byte. the receive cell processor will then compare this locally computed hec byte value with that of the fifth octet, within the incoming cell. if the two hec byte values are equal, then the cell is then retained for further processing. if the two hec byte values are not equal, then most of the cells with single-bit errors are corrected. however, the cell is optionally discarded if multiple-bit errors are detected. ? idle cell filtering the receive cell processor will detect and (optionally) remove idle cells. and can be configured to filter user and oam cells. ? user cell filtering the receive cell processor can be configured to filter user or oam cells, based upon their header byte patterns. ? the receive cell processor will (optionally) de-scramble the payload portion of the cell (the 6th through the 53rd octet), and pack these octets in with the cell header bytes, and the hec byte for transmission to the receive utopia interface block. the following sections discuss the blocks comprising the receiver section of the e3 uni in detail. 7.1 receive e3 framer 7.1.1 brief description of the receive e3 framer the receive e3 framer receives the e3 frame data from the line, via the rxpos, rxneg, and rxlineclk input pins; and it synchronizes itself to the incoming e3 data-stream. it decodes and frames the incoming data into e3 frames. the receive e3 framer supports the itu-t g.832 compliant e3 framing format. it detects line code viola- tions (lcv), the loss of signal (los), the alarm indication status (ais), out of frame (oof), and loss of frame (lof) conditions. the receive e3 framer computes the bip-8 values over a given e3 frame and compares it that within the em byte-field in the very next incoming e3 frame. it extracts and processes the e3 frame overhead bytes and provides them to a serial output port. finally, the receive e3 framer will receive lapd message frames from the ?far-end? transmit e3 framer. afterwards, the lapd receiver (within the receive e3 framer) will extract out the pmdl messages from the lapd message frames, and will write it into the ?receive lapd message? buffer.
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 220 the receive e3 framer will detect and generate interrupts upon error conditions. the status of the receive e3 framer can be read by registers through the uni-microprocessor interface. the receive e3 framer will route the contents of the e3 frame payload to the receive cell processor. figure 52 presents a simple block diagram of the receive e3 framer along with the associated pins. additionally, figure 53 presents a more in-depth functional block diagram of the receive e3 framer. figure 52. simple block diagram of the receive e3 framer, with associated pins rxpos rxneg rxais rxohclk rxoh rxlos rxframe rxoof rxlof rx framer from e3 liu to receive cell processor rxlineclk rlos rxohframe
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 221 figure 53. functional block diagram of the receive e3 framer 7.1.2 detailed functional description of the receive e3 framer 7.1.2.1 receiving and decoding incoming e3 data?via the e3 line when incoming pulses, within the e3 line signal arrive at a ?receiving? terminal, the e3 line signal is typically received by the ?line interface unit? (liu) device. the liu will recover the clock and data from the e3 line signal, and output this data to the receive e3 framer via the rxpos, rxneg, and rxlineclk input pins. therefore, the receive e3 framer will receive both timing and data information from the incoming e3 data stream. the e3 timing information will be received via the rxlineclk input pin; and the e3 frame data information will be received via the rxpos and rxneg input pins. the receive e3 framer is capable of receiving e3 data pulses in either the ?unipolar? or ?bipolar? modes. if the receive e3 framer is operating in the ?bipolar? mode, then it can be configured to decode either ami or hdb3 line code data. each of these input formats and line codes will be discussed in detail, below. hdb3 decoder rxe3 registers receive frame synchronizer oh extractor bip-8 verifier framing byte verifier payload type validator ferf bit validator timing marker validator rx lapd processor rx lapd ram (88 bytes) interrupt generator parallel to serial converter rxpos rxneg rxlineclk rxoh rxframe rxohclk rxohframe rxoof ais lof los cofa rxe3 int to reg. lapd msg rcv?d ferf change payload type mismatch framing byte error bip-8 error los lof cofa ais data bus extracted oh bytes cell data to rxcp sync byte data register select read write data bus control signals ttb change indicator status signal decoded serial data frame pulse
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 222 7.1.2.1.1 unipolar mode decoding if the receive e3 framer is operating in the ?unipolar? mode, then it will receive the single rail nrz e3 data pulses via the rxpos input pin. the receive e3 framer will also receive its timing signal via the rxlineclk signal. however, no data pulses will be applied to the rxneg input pin. the receive e3 framer receives a logic ?1? when a logic ?1? level signal is present at the rxpos input pin, during the sampling edge of the rxlineclk signal. likewise, a logic ?0? is received when a logic ?0? level signal is applied to the rxpos pin. figure 54 presents an illustration of the behavior of the rxpos, rxneg, and rxlineclk pins when the uni is receiving e3 frame data, while operating in the unipolar mode. figure 54. behavior of the rxpos, rxneg, and rxlineclk signals during data reception of unipolar data note: operating the uni in the unipolar mode is recommended if the user intends to transmit and receive the e3 frame data over optical fiber. however, if the user intends to transmmit and receive the e3 data over a transformer- coupled copper medium (e.g., coaxial cable), then he/she is urged to operate the uni in the ?bipolar? mode. the user can configure the receive e3 framer to operate in either the unipolar or the bipolar mode by writing the appropriate value into bit 3 (unipolar/bipolar*) within the ?uni i/o control? register, as depicted below. the following table relates the value within bit 3 (unipolar/bipolar*) to the receive e3 framer line interface input mode . uni i/o control register (address = 01h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 loc rx loc tx interrupt enable reset ami/ hdb3* unipolar/ bipolar* txline clk inv rxline clk inv reframe ro ro r/w r/w r/w r/w r/w r/w 0 0 x 1 0 x x 0 table 26. the relationship between the contents of bit 3 (unipolar/bipolar*) within the uni i/o control register and the result ing receive e3 framer line interface input mode bit 3 receive e3 framer line interface input mode 0 bipolar mode (dual rail): e3 fra]me data is receive via both the rxpos and the rxneg input pins. 1 unipolar mode (single-rail): e3 frame data is received via only the rxpos input pin. no e3 frame data is received via the rxneg input pin. rxpos rxneg rxlineclk data 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 223 note: 1. the default condition is the bipolar mode 2. this selection also effects the transmit e3 framer line interface output mode 7.1.2.1.2 bipolar mode decoding if the receive e3 framer is operating in the bipolar mode, then it will receive the e3 data pulses via both the rxpos and rxneg inputs. additionally, the receive e3 framer will also receive the e3 timing signal via the rxlineclk input pin. figure 55 presents a circuit diagram illustrating how the receive e3 framer interfaces to the line interface unit while the uni is operating in the bipolar mode. if the receive e3 framer is operating in the ?bipolar? mode, then it can be configured to decode either the ami or hdb3 line codes. figure 55. illustration on how the receive e3 framer interfaces to the line interface unit, while the uni is operating in the bipolar mode. the bipolar mode is the ?mode of choice? if the user intends to transmit and receive e3 data over transformer-coupled copper medium (e.g., coaxial cable). this is because the bipolar line codes (ami and hdb3) contain no dc compo- nents; thereby eliminating dc distortion in the line. the role of the rxpos, rxneg, and rxlineclk input pins, for the bipolar mode are discussed below. rxpos?receive ?positive-polarity? pulse the external liu will assert this input pin, when it is receiving a ?positive-polarity? pulse from the line. rxneg?receive ?negative-polarity? pulse the external liu will assert this input pin, when it is receiving a ?negative-polarity? pulse from the line. 5v t1 pe 65966 t2 pe 65966 r1 39 r2 39 r3 39 r4 270 r6 36 r5 270 r7 36 c2 0.01uf c1 0.1uf u2 xr-t7296 ds3, sts-1/e3 4 encodis 11 decodis 12 tndata 8 tpdata 7 tclk 9 rclko 17 rneg 15 rpos 16 rloop 2 taos 5 lloop 3 dmo 18 txlev 25 ttip 23 tring 22 mtip 20 mring 19 rclk 1 rpdata 27 rndata 28 u? XR-T7234 txneg 111 txpos 109 txlineclk 112 rxlineclk 99 rxneg 98 rxpos 97 txaddr0 147 txaddr1 149 txaddr2 150 txaddr3 148 txaddr4 146 txdata15 144 txdata14 142 txdata13 140 txdata12 138 txdata11 134 txdata10 132 txdata9 130 txdata8 128 txdata7 143 txdata6 141 txdata5 139 txdata4 137 txdata3 135 txdata2 133 txdata1 131 txdata0 129 rxdata0 70 rxdata1 68 rxdata2 64 rxdata3 62 rxdata4 60 rxdata5 58 rxdata6 56 rxdata7 54 rxdata8 69 rxdata9 67 rxdata10 65 rxdata11 63 rxdata12 61 rxdata13 57 rxdata14 55 rxdata15 53 rxaddr0 79 txclav 126 txsoc 124 txprty 125 txclk 151 txenb 123 rxclav 76 rxsoc 72 rxprty 74 rxclk 50 rxenb 81 rxaddr1 80 rxaddr2 77 rxaddr3 75 rxaddr4 73 encodis 22 rloop 26 lloop 28 reqb 12 rlos 86 rlol 8 taos 2 txlev 24 dmo 6 u? xr-t7295e rlos 7 rlol 8 lpf1 4 lpf2 5 exclk 13 rndata 12 rpdata 16 rclk 14 rin 2 reqb 18 ttip tring 34.386 mhz rtip rring txdata[15:0] txaddr[4:0] rxaddr[4:0] rxdata[15:0] txsoc txprty 50mhz txenb 50mhz rxenb txclav rxclav rxsoc rxprty
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 224 rxlineclk?receive line clock this signal is the ?recovered clock? output signal, which the liu has extracted from the incoming e3 line signal. theuni ic uses this signal, to sample the state of the rxpos and rxneg input pins. 7.1.2.1.2.1 ami decoding in the ami or alternate mark inversion line code, consecutive ?one?s? (or mark) pulses will be of opposite polarity with respect to each other. this line code involves the use of three different amplitude levels: ?+1?, ?0?, and ?-1?. the ?+1? and ?-1? amplitude signals are used to represent the one?s (or mark) pulses in the e3 data-stream. the ?0? amplitude pulses (or the absence of a pulse) are used to represent zeros (or space) pulses, in the e3 data-stream. the general rule for ami is: if a given ?mark? pulse is of positive polarity, then the very next ?mark? pulse will be of negative polarity, and vice versa. this alternating-polarity relationship exists between two consecutive mark pulses, independent of the number of zeros that exist between these two pulses. the line interface unit has the task of receiving the line signal and converting it into a ?dual-rail? format (e.g., positive-polarity data and negative-polarity data). the two signals that comprise the ?dual-rail? format are applied to the rxpos and rxneg input pins of the uni. figure 56 presents an illustration of the ami line code as would appear at the rxpos and rxneg pins of the uni, as well as the incoming line signal. figure 56. illustration of the ami line code 7.1.2.1.2.2 hdb3 decoding the transmit e3 framer, and the associated liu embed and combine the e3 frame data and clocking information into the line signal that is transmitted to the ?far-end? terminal. the line interface unit and receive e3 framer at the ?far-end? terminal, has the task of recovering this data and timing information from the incoming e3 data stream. most e3 lius, on the market today, employ clock and data recovery schemes that rely on the use of phase-locked- loop (pll) circuitry. the pll circuitry, within the liu, assists in the clock and data recovery process by ?locking? onto the transitions in the e3 line signal. therefore, these clock recovery schemes are vulnerable to the occurrence of a long stream of consecutive zeros (e.g., no transitions in the line). this scenario can cause the pll to lose ?lock? with the incoming e3 data, thereby causing the ?clock? and data recovery process of the liu device to fail. therefore, some approach is needed to insure that such a long string of consecutive zeros can never happen. one standard technique that is used in the e3 transport medium is ?hdb3 encoding?. in general, the hdb3 line code behaves just like ami; with the exception of the case when a long string of consecutive zeros occurs on the line. in hdb3 line coding, any string of 4 consecutive zeros will be replaced with either a ?000v? or a ?b00v? where ?b? refers to a bipolar pulse (e.g., a pulse with a polarity that is compliant with the ami coding rule). and ?v? refers to a bipolar violation pulse (e.g., a pulse with a polarity that violates the alternating polarity scheme of ami.) the decision between insert- ing an ?000v? or a ?b00v? is made to insure that an odd number of bipolar (b) pulses exist between any two bipolar violation (v) pulses. the receive e3 framer, when operating with the hdb3 line code is responsible for decoding data rxpos rxneg line signal 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 225 the hdb3-encoded data (e.g., substituting the ?000v? or ?b00v? pattern with 4 consecutive ?0s?.) in order to restore the data (transmitted over the e3 transport medium) into its original format. figure 57 presents a timing diagram that illustrates the following. ? the ?bipolar? pulses of the incoming e3 line signal. ? the resulting ?dual-rail? input signals applied to the rxpos and rxneg input pins of the uni (note this signal is still in the hdb3-format). ? the ?hdb3 decoded? e3 data stream (in the ?data? row of this figure). figure 57. illustration of two examples of hdb3 decoding note: figure 57 presents two examples of hdb3-decoding, which is accomplished by the receive e3 framer block (within the uni device). in the first example, a ?000v? pattern is decoded back into a string of ?4? consecutive zeros. in the second example, a ?b00v? pattern is decoded back into a string of ?4? consecutive zeros. 7.1.2.1.2.3 line code violations the receive e3 framer will also check the incoming e3 data stream for line code violations. for example, if the receive e3 framer detects the occurrence of a bipolar violation pulse that is determined to be invalid, (e.g., the bipolar violation pulse is not involved in the substitution of an ?000v? or a ?b00v? pattern in the place of 4 consecu- tive ?0s?.) then an lcv (line code violation) is flagged and the receive e3 framer will increment the ?pmon lcv event count-msb/lsb? registers (address = 40h and 41h). additionally, the lcv-one second accumulation reg- isters will also be incremented. another example of a line code violation would be: if the incoming e3 data is hdb3 encoded, and if four (or more) consecutive zeros are received in the e3 line signal. such an event would also cause the receive e3 framer to increment these pmon lcv registers. the user can determine the number of line code violation events that have been detected by the receive e3 framer, by reading the pmon lcv event count registers. the bit-format for these registers is presented below pmon lcv event count register?msb (address = 40h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 lcv event count?high byte rur rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0 data 0 0 0 v line signal b 0 0 v rxpos rxneg 1 1 1 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 226 these registers contain a 16-bit expression on the number of line code violation events that have been detected since the last read of these registers. these registers are reset upon read. 7.1.2.1.3 rxlineclk clock edge selection the incoming unipolar or bipolar data, applied to the rxpos and the rxneg input pins are clocked into the receive e3 framer via the rxlineclk signal. the uni allows the user to specify which edge (e.g., rising or falling) of the rxlineclk signal will sample and latch the signals at the rxpos and rxneg input pins into the uni. the user can make this selection by writing the appropriate data to bit 1 (rxlineclk inv) of the ?uni i/o control? register, as depicted below. the following table relates the contents of this bit-field to the sampling clock edge of the rxlineclk signal (e.g., the edge of the rxlineclk signal that the e3 data, input at the rxpos and rxneg pins, are sampled and latched into the receive e3 framer). pmon lcv event count register?lsb (address = 4h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 lcv event count?low byte rur rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0 uni i/o control register (address = 01h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 loc rx loc tx interrupt enable reset ami/ hdb3* unipolar/ bipolar* txline clk inv rxline clk inv reframe ro ro r/w r/w r/w r/w r/w r/w 0 0 x 1 0 x x 0 table 27. the relationship between the contents of bit 1 (rxlineclk inv) within the ?uni i/o control? register, and the sampling edge of the rxlineclk signal. rxlineclk inv (bit 1) sampling edge of rxlineclk 0 rising edge: inputs at the rxpos and/or rxneg pins are sampled and latched into the receive e3 framer circuitry on the rising edge of the rxlineclk signal. see figure 58 for the timing relationship between rxlineclk, rxpos, and rxneg; for this selection. 1 falling edge: inputs at the rxpos and/or rxneg pins are sampled and latched into the receive e3 framer circuitry on the falling edge of the rxlineclk signal. see figure 59 for the timing relationship between rxlineclk, rxpos and rxneg; for this selection.
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 227 figures 58 and 59 present the waveform and timing relationships between rxlineclk, rxpos, and rxneg for each of these configurations. figure 58. waveform/timing relationship between rxlineclk, rxpos and rxneg?when rxpos and rxneg are to be sampled on the rising edge of rxlineclk figure 59. waveform/timing relationship between rxlineclk, rxpos and rxneg - when rxpos and rxneg are to be sampled on the rising edge of rxlineclk. 7.1.2.2 e3 frame synchronization once the incoming hdb3 (or ami) encoded data has been decoded into a binary data-stream, the ?receive frame synchronizer? section of the receive e3 framer will use portions of this data-stream in order to synchronize itself to the ?far-end? transmit e3 framer. at any given time, the ?receive frame synchronizer? section of the receive e3 framer will be operating in one of two framing modes. ? the frame acquisition mode: in this mode, the receive e3 framer is trying to acquire synchronization with the incoming e3 frame, or ? the frame maintenance mode: in this mode, the receive e3 framer is trying to maintain frame synchronization with the incoming e3 frame. rxlineclk rxpos rxneg t38 t39 t42 rxlineclk rxpos rxneg t40 t41
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 228 each of these two framing modes are discussed in detail below. the receive e3 framer will transition between the ?frame acquisition? mode and the ?frame maintenance? mode, in accordance with the ?e3 frame acquisition/ maintenance? algorithm. throughout the discussion of the e3 framing acquisition/maintenance algorithm, the reader will be referred to figure 60. figure 60 presents a state machine diagram that depicts the receive e3 framer?s ?e3 frame acquisition/maintenance? algorithm. figure 60. the state machine diagram for the receive e3 framer?s ?e3 frame acquisition/maintenance? algorithm 7.1.2.2.1 the framing acquisition mode the receive e3 framer is considered to be operating in the ?frame acquisition mode, if it is operating in any one of the following states within the ?e3 frame acquisition/maintenance? algorithm, per figure 60. ? fa1, fa2 octet search state ? fa1, fa2 octet verification state ? oof condition state ? lof condition state fa1, fa2 octet search fa1, fa2 octet verification in frame oof condition lof condition fa1 and fa2 octets are detected once fa1 and fa2 octets are verified once fa1 and fa2 octets are not detected 4 consecutive in-valid frames 3 consecutive valid frames 1 or 3 ms of operating in the oof condition (user-selectable) frame maintenance mode
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 229 each of these ?framing acquisition? states, within the receive e3 framer ?framing acquisition/maintenance? state machine are discussed below. the ?fa1, fa2 octet search? state when the receive e3 framer is first powered up, it will be operating in the ?fa1, fa2 octet search? state. while the receive e3 framer is operating in this state, it will be performing a bit-by-bit search for the fa1 and fa2 framing alignment octets. fa1 is assigned the value of f6h; and fa2 is assigned the value of 28h. figure 61, which present s an illustration of the itu-t g.832 compliant e3 frame format, indicates that these two octets will occur at the beginning of each e3 frame, and that the fa2 octet will appear immediately after the fa1 octet. figure 61. illustration of the itu-t g.832 complaint e3 frame format fa1 fa2 em 530 octet payload tr ma nr gc 1 byte 59 bytes
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 230 when the receive e3 framer detects the fa1 octet, and determines that this octet is immediately followed by fa2 octet, then it will transition to the ?fa1, fa2 octet verification? state, per figure 60. the ?fa1, fa2 octet verification? state once the receive e3 framer has detected an ?f628h? pattern (e.g., the concatenation of the fa1 and the fa2 octets), it must verify that this pattern is indeed the fa1 and fa2 octets, and not some other set of bytes, within the e3 frame, mimicking the frame alignment bytes. hence, the purpose of the ?fa1, fa2 octet verification? state. when the receive e3 framer enters this state, it will then quit performing its ?bit-by-bit? search for the frame alignment bytes. instead, the receive e3 framer will read in the two octets that occur 537 bytes (e.g., one e3 frame period later) after the ?candidate? frame alignment patterns were first detected. if these two bytes match the assigned values for the fa1 and fa2 octets, then the receive e3 framer will conclude that it has found the frame alignment bytes and will then transition to the ?in-frame? state. however, if these two bytes do not match the assigned values for the fa1 and fa2 octets, then the receive e3 framer will concluded that it has been ?fooled? by data mimicking the frame alignment bytes, and will transition back to the ?fa1, fa2 octet search? state. in-frame state once the receive e3 framer enters the ?in-frame? state, then it will cease performing ?frame acquisition? functions, and will proceed to perform ?framing maintenance? functions. therefore, the operation of the receive e3 framer, while operating in the ?in-frame? state, can be found in section 7.1.2.2.2 (the framing maintenance mode). oof (out of frame) condition state if the receive e3 framer, while operating in the ?in-frame? state detects 4 consecutive frames, which do not have the valid frame alignment (fa1 and fa2 octet) patterns, then it will transition into the ?oof condition state?. the receive e3 framer?s operation, while in the ?oof condition? state is a unique mix of framing maintenance and framing acquisition operation. the receive e3 framer will exhibit some framing acquisition characteristics by attempting to locate (once again) the frame alignment octets. however, the receive e3 framer will also exhibit some frame maintenance behavior by still using the most recent frame synchronization for its oh byte and payload byte processing. the receive e3 framer will inform the local m p of its transition from the ?in-frame? state to the ?oof condition? state, by generating a ?change in oof condition? interrupt. when this occurs, bit 3 (oof interrupt status), within the ?rx e3 interrupt status register-1?, will be set to ?1?, as depicted below. the receive e3 framer will also inform the external circuitry of its transition into the ?oof condition? state, by toggling the rxoof output pin ?high?. if the receive e3 framer is capable of finding the frame alignment octets within a ?user-selectable? number of e3 frame periods, then it will transition back into the ?in-frame? state. the receive e3 framer will inform the local m p of its transition back into the ?in-frame? state by generating the ?change in oof condition? interrupt. address = 12h, rx e3 interrupt status register-1 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused cofa interrupt status oof interrupt status lof interrupt status los interrupt status ais interrupt status ro ro ro ro ro ro ro ro 0 0 0 0 1 0 0 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 231 however, if the receive e3 framer resides in the ?oof condition? state for more than this ?user-selectable? number of e3 frame periods, then it will automatically transition to the ?lof condition? state. the user can select this ?user-selectable? number of e3 frame periods that the receive e3 framer will remain in the ?oof condition? state by writing the appropriate value to bit 7 (rxlof algo) within the ?rx e3 configuration & status register, as depicted below. writing a ?0? into this bit-field causes the receive e3 framer to reside in the ?oof condition? state for at most 24 e3 frame periods (3 ms). writing a ?1? into this bit-field causes the receive e3 framer to reside in the ?oof condition? state for at most 8 e3 frame periods (1 ms). lof (loss of framing) condition state if the receive e3 framer enters the lof condition state, then the following things will happen. ? the receive e3 framer will discard the most recent frame synchronization; and ? the receive e3 framer will make an unconditional transition to the ?fa1, fa2 octet search? state. ? the receive e3 framer will notify the local m p of its transition to the ?lof condition? state, by generating the ?change in lof condition? interrupt. when this occurs, bit 2 (lof interrupt status) within the ?rx e3 interrupt status register-1? will be set to ?1?, as depicted below. finally, the receive e3 framer will also inform the external circuitry of its transition to the ?lof condition? state by toggling the ?rxlof? output pin ?high?. rx e3 configuration & status register (address = 0fh) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rxlof algo rxlof rxoof rxlos rxais rxpld unstb rx tmark rxferf r/w ro ro ro ro ro ro ro x 0 0 0 0 x x x address = 12h, rx e3 interrupt status register-1 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused cofa interrupt status oof interrupt status lof interrupt status los interrupt status ais interrupt status ro ro ro ro ro ro ro ro 0 0 0 0 0 1 0 0
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 232 7.1.2.2.2 the framing maintenance mode once the receive e3 framer enters the ?in-frame? state, then it will notify the local m p of this fact by generating both the ?change in oof condition? and the ?change in lof condition? interrupts. when this happens, bit 2 and 3 (lof interrupt status and oof interrupt status) will be set to ?1?, as depicted below. additionally, the receive e3 framer will inform the external circuitry of its transition to the ?in-frame? state by toggling both the rxoof and the rxlof output pins low. finally, the receive e3 framer will negate both the ?rxoof? and the ?rxlof? bit-fields within the ?rx e3 configuration & status register, as depicted below. when the receive e3 framer is operating in the ?in-frame? state, it will then begin to perform ?frame maintenance? operations; where it will continue to verify that the frame alignment octets (fa1, fa2) are present, at their proper locations. while the receive e3 framer is operating in the ?frame maintenance? mode, it will declare an ?out-of- frame? (oof) condition if it detects invalid framing alignment bytes in four consecutive frames. since the receive e3 framer requires the detection of invalid frame alignment bytes in four consecutive frames, in order for it to transition to the ?oof condition? state, it can tolerate some errors in the frame alignment bytes, and still remain in the ?in-frame? state. however, each time the receive e3 framer detects an error in the ?frame alignment? bytes, it will increment the pmon framing error event count registers (address = 42h and 43h). the bit-format for these two registers are depicted below. address = 12h, rx e3 interrupt status register-1 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused cofa interrupt status oof interrupt status lof interrupt status los interrupt status ais interrupt status ro ro ro ro ro ro ro ro 0 0 0 0 1 1 0 0 rx e3 configuration & status register (address = 0fh) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rxlof algo rxlof rxoof rxlos rxais rxpld unstb rx tmark rxferf r/w ro ro ro ro ro ro ro x 0 0 0 0 x x x pmon framing error event count?msb (address = 42h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 frame alignment error count?high byte ro ro ro ro ro ro ro ro
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 233 7.1.2.2.3 forcing a reframe via software command the uni allows the user to command a reframe procedure with the receive e3 framer via software command. if the user writes a ?1? into bit 0 (reframe) within the uni i/o control register, as depicted below; then the receive e3 framer will be forced into the ?fa1, fa2 octet search? state, per figure 60, and will begin its search for the fa1 and fa2 octets. the uni will also respond to this command by doing the following. 1. asserting both the rxoof and rxlof output pins. 2. generating both the ?change in oof status? and the ?change in lof status? interrupts to the local m p. 3. asserting both the rxlof and the rxoof bit-fields within the rx e3 configuration & status register, as depicted below. pmon framing error event count?lsb (address = 42h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 frame alignment error count?low byte ro ro ro ro ro ro ro ro uni i/o control register (address = 01h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 loc rx loc tx int en reset ami/ hdb3* unipolar/bipolar* txclk inv rxclk inv reframe ro ro r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 1 rx e3 configuration & status register (address = 0fh) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rxlof algo rxlof rxoof rxlos rxais rxpld unstb rx tmark rxferf r/w ro ro ro ro ro ro ro x 1 1 0 0 x x x
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 234 7.1.2.2.4 performance monitoring of the frame synchronization section of the receive e3 framer the user can monitor the number of framing bytes (fa1 and fa2 bytes) errors that have been detected by the receive e3 framer. this is accomplished by periodically reading the pmon framing error event count registers (address = 42h and 43h). the byte format of these registers are presented below. when the local m p/ m c reads these register, it will read in the number of errors, that have been detected in the frame alignment octets (fa1 and fa2), since the last read of these two registers. these registers are reset upon read. 7.1.2.2.5 the rxoof and rxlof output pins the user can roughly determine the current framing state that the receive e3 framer is operating in by reading the logic states of the rxoof and the rxlof output pins. table 28, presents this relationship between the state of the rxoof and rxlof output pins, and the framing state of the receive e3 framer. table 28, the relationship between the logic state of the rxoof and rxlof output pins and the framing state of the receive e3 framer pmon framing error event count register?msb (address = 42h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 frame alignment byte error count?high byte ro ro ro ro ro ro ro ro 0 0 0 0 0 0 0 0 pmon framing error event count register?lsb (address = 43h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 frame alignment byte error count ?low byte ro ro ro ro ro ro ro ro 0 0 0 0 0 0 0 0 rxlof rxoof framing state 0 0 in frame 0 1 oof condition (the receive e3 framer is operating inthe 3 ms oof period). 1 0 invalid 1 1 lof condition
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 235 7.1.2.3 e3 receive alarms 7.1.2.3.1 the loss of signal (los) alarm asserting the los indicators the receive e3 framer will declare a ?loss of signal (los) condition, when it detects 32 consecutive incoming ?0s? via the rxpos and rxneg input pins or if the rlos input pin (from the xr-t7295e e3 line receiver ic) is asserted. the receive e3 framer will indicate the occurrence of an los condition by: ? asserting the rxlos output pin (e.g., toggles it ?high?). ? setting bit 4 of the rx e3 configuration/status register to ?1?, as depicted below. ? the receive e3 framer will generate a ?change in los status? interrupt request. upon generating this interrupt request, the receive e3 framer will assert bit 1 (los interrupt status) within the ?rx e3 framer interrupt status register-1; as depicted below. negating the los indicators the receive e3 framer will negate the ?los? condition when it encounters a stream of 32 bits that does not contain a string of 4 consecutive zeros. when the receive e3 framer negates the los status, then it will notify the local m p and the external circuitry of this occurrence by: ? generating the ?change in los status? interrupt to the local m p. rx e3 configuration/status register (address = 0fh) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rxlof algo rxlof rxoof rxlos rxais rxpld unstb rx tmark rxferf r/w ro ro ro ro ro ro ro 0 x x 1 0 x x x rx e3 framer interrupt status register-1 (address = 12h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused cofa interrupt status oof interrupt status lof interrupt status los interrupt status ais interrupt status ro ro ro rur rur rur rur rur 0 0 0 x x x 1 0
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 236 ? negating bit 4 (rxlos) within the ?rx e3 configuration & status? register, as depicted below. ? negate the rxlos output pin (e.g., toggle it low). 7.1.2.3.2 alarm indication signal (ais) condition asserting the ais condition the receive e3 framer will identify and declare an ?ais? condition, if it detects an ?all ones? pattern in the incoming e3 data stream. more specifically, the receive e3 framer will declare an ais condition, if 7 or less ?0s? are detected in each of 2 consecutive frames. if the receive e3 framer declares an ?ais condition?, then it will ? generating the ?change in ais condition? interrupt to the local m p. hence, the receive e3 framer will assert bit 1 (ais interrupt status) within the ?rx e3 framer interrupt status register-1?, as depicted below. ? assert the rxais output pin. ? set bit 3 (rxais)of the rx e3 configuration/status register, as depicted below. rx e3 configuration/status register (address = 0fh) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rxlof algo rxlof rxoof rxlos rxais rxpld unstb rx tmark rxferf r/w ro ro ro ro ro ro ro 0 x x 0 0 x x x rx e3 framer interrupt status register-1 (address = 12h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused cofa interrupt status oof interrupt status lof interrupt status los interrupt status ais interrupt status ro ro ro rur rur rur rur rur 0 0 0 x x x 0 1 rx e3 configuration/status register (address = 0fh) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rxlof algo rxlof rxoof rxlos rxais rxpld unstb rx tmark rxferf r/w ro ro ro ro ro ro ro 0 x x 0 1 x x x
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 237 negating the ais condition the receive e3 framer will negate the ?ais? condition when it detects two consecutive e3 frames, with eight or more ?zeros? in the incoming data stream. the receive e3 framer will inform the local m c/ m p of this negation of the ?ais? condition, by: ? generating a ?change in ais condition? interrupt to the local m p. hence, the receive e3 framer will assert bit 1 (ais interrupt status) within the ?rx e3 framer interrupt status register-1?. ? negating the rxais output pin (e.g., toggling it ?low?) ? setting the rxais bit-field, within the rx e3 configuration/status register, to ?0?, as depicted below. 7.1.2.3.3 the far-end receive failure (ferf) condition asserting the ferf condition the receive e3 framer will declare a ?far-end-receive-failure? (ferf) condition if it detects a ?user-selectable? number of consecutive incoming e3 frames, with the ?ferf? bit-field (bit 7 within the ma byte) set to ?1?. the bit format of the ma byte is presented below. this ?user-selectable? number of e3 frames is either 3 or 5 depending upon the value that has been written into bit 4 (rx ferf algo) of the rx e3 configuration/status register, as depicted below. rx e3 configuration/status register (address = 0fh) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rxlof algo rxlof rxoof rxlos rxais rxpld unstb rx tmark rxferf r/w ro ro ro ro ro ro ro 0 x x 0 0 x x x bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 ferf febe payload type payload dependent timing marker 1 x 0 1 0 x x x rx e3 configuration/status register (address = 0eh) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rxpldtype[2:0] rxferf algo rx tmark algo rxpldexp[2:0] ro ro ro r/w r/w r/w r/w r/w 0 1 0 0 0 0 1 0
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 238 writing a ?0? to this bit-field causes the receive e3 framer to declare an ?ferf? condition, if it detects 3 consecu- tive incoming e3 frames, that have the ?ferf? bit (within the ma byte) set to ?1?. writing a ?1? to this bit-field causes the receive e3 framer to declare an ?ferf? condition, if it detects 5 consecutive incoming e3 frames, that have the ?ferf? bit (within the ma byte) set to ?1?. whenever the receive e3 framer declares a ?ferf? condition, then it will do the following ? generate a ?change in ferf condition? interrupt to the local m p. hence, the receive e3 framer will assert bit 3 (ferf interrupt status) within the ?rx e3 framer interrupt status register-2?; as depicted below. ? set the ?rxferf? bit-field, within the rx e3 configuration/status register, to ?1?, as depicted below. negating the ferf condition the receive e3 framer will negate the ferf condition once it has received a ?user-selectable? number of consec- utive incoming e3 frames with the ?ferf? bit-field set to ?0?. this ?user-selectable? number of e3 frames is either 3 or 5 depending upon the value that has been written into bit 4 (rx ferf algo) of the ?rx e3 configuration/status register, as discussed above. whenever the receive e3 framer negates the ferf status, then it will do the following. 1. generate a ?change in the ferf status? interrupt to the local m p. 2. negate bit 0 (rx ferf) within the rx e3 configuration & status register, as depicted below. rx e3 framer interrupt status register-2 (address = 13h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused ttb change interrupt status lapd interrupt status febe interrupt status ferf interrupt status bip-8 error interrupt status framing byte error interrupt status rx pld mis interrupt status ro rur rur rur rur rur rur rur 0 0 0 0 1 0 0 0 rx e3 configuration/status register (address = 0fh) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rxlof algo rxlof rxoof rxlos rxais rxpld unstb rx tmark rxferf r/w ro ro ro ro ro ro ro x 0 0 0 0 0 x 1 rx e3 configuration/status register (address = 0fh) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rxlof algo rxlof rxoof rxlos rxais rxpld unstb rx tmark rxferf r/w ro ro ro ro ro ro ro x 0 0 0 0 0 x 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 239 7.1.2.4 error-checking of the incoming e3 frames the receive e3 framer performs error-checking on the incoming e3 frame data that it receives from the ?far-end? terminal. it performs this error checking by computing the bip-8 value of an incoming e3 frame. once the receive e3 framer has obtained this value, it will compare this value with that of the em byte that it receives, within the very next e3 frame. if the ?locally computed? bip-8 value matches the em byte of the corresponding e3 frame, then the receive e3 framer will conclude that this particular frame has been properly received. the receive e3 framer will then inform the ?far-end? terminal of this fact by having the ?near-end? transmit e3 framer send the ?far-end? terminal an e3 frame, with the ?febe? bit-field, within the ma byte, set to ?0?. this procedure is illustrated in figure 62 and 63, below. figure 62 illustrates the ?near-end? receive e3 framer receiving an ?error-free? e3 frame. in this figure, the locally computed bip-8 value of ?5ah? matches that received from the ?far-end? terminal, within the em byte-field. figure 63 illustrates the subsequent action of the ?near-end? transmit e3 framer, which will transmit an e3 frame, with the febe bit-field set to ?0?; to the ?far-end? terminal. this signaling indicates that the ?near-end? receive e3 framer has received an ?error-free? e3 frame. figure 62. illustration of the ?near-end? receive e3 framer, receiving an e3 frame (from the ?far-end? terminal) with a correct em-byte. transmit e3 framer receive e3 framer near-end terminal far-end terminal em byte locally calculated em byte 5ah 5ah
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 240 figure 63. illustration of the ?near-end? transmit e3 framer, transmitting an e3 frame (to the ?far-end? terminal) with the febe bit (within the ma byte-field) set to ?0?. however, if the locally computed bip-8 value does not match the em byte of the corresponding e3 frame, then the receive e3 framer will do the following. ? it will inform the ?far-end? terminal of this fact by having the ?near-end? transmit e3 framer send the ?far-end? terminal an e3 frame, with the ?febe? bit-field, within the ma byte, set to ?1?. this phenomenon is illustrated below in figures 64 and 65. transmit e3 framer receive e3 framer near-end terminal far-end terminal ma byte x0xxxxxx febe bit
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 241 figure 64 illustrates the ?near-end? receive e3 framer receiving an ?errored? e3 frame. in this figure, the ?near-end? receive e3 framer is receiving an e3 with an em byte containing the value ?5ah?. this value does not match the ?locally computed? em byte value of ?5bh?. consequently, there is an error in this e3 frame. figure 65 illustrates the subsequent action of the ?near-end? transmit e3 framer, which will transmit an e3 frame, with the febe bit-field set to ?1? to the ?far-end? terminal. this signaling indicates that the ?near-end? receive e3 framer has received an ?errored? e3 frame. figure 64. illustration of the ?near-end? receive e3 framer receiving an e3 frame (from the ?far-end? terminal) with transmit e3 framer receive e3 framer near-end terminal far-end terminal em byte locally calculated em byte 5ah 5bh
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 242 an incorrect em-byte. figure 65. illustration of the ?near-end? transmit e3 framer, transmitting an e3 frame (to the ?far-end? terminal) with the febe bit (within the ma byte-field) set to ?1?. ? in addition to the ?febe? bit-field signaling; the receive e3 framer will generate the ?bip-8 error? interrupt to the local m p. hence, it will set bit 2 (bip-8 error interrupt status) to ?1? as depicted below. rx e3 framer interrupt status register-2 (address = 13h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused ttb change interrupt status lapd interrupt status febe interrupt status ferf interrupt status bip-8 error interrupt status framing byte error interrupt status rx pld mis interrupt status ro rur rur rur rur rur rur rur 0 0 0 0 0 1 0 0 transmit e3 framer receive e3 framer near-end terminal far-end terminal ma byte x1xxxxxx febe bit
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 243 ? finally, the receive e3 framer will increment the ?pmon framing bip-8 error count? register. the byte format of these registers are presented below. the user can determine the number of bip-8 errors that have been detected by the receive e3 framer, since the last read of these registers. these registers are reset upon read. 7.1.2.5 lapd receiver the lapd transceiver uses either the gc byte-field or the nr byte-field, within each e3 frame to transmit and receive performance monitor data link (pmdl) messages. the ?far-end? lapd transmitter will transmit a pmdl message, encapsulated in a lapd message frame to the ?near-end? lapd receiver, via one of these two byte- fields, within each incoming e3 frame. the lapd receiver will receive and extract the pmdl message from the incoming lapd message frame. afterwards, the lapd receiver will write the pmdl message into the ?receive lapd message? buffer, which is located at addresses: deh through 135h, within the on-chip ram. the lapd receiver (within the ?near-end? receive e3 framer) has the following responsibilities. ? receiving the incoming lapd message frame octets and reassembling these octets into lapd message frames. ? filtering out stuffed ?0s? (within the pmdl message portion of the lapd message frame). ? extracting the pmdl message from the incoming lapd message frame, and writing the pmdl message into the ?receive lapd message? buffer. ? performing frame check sequence (fcs) verification of the incoming lapd message frame. ? provide status indicators for ? end of message (eom) ? flag sequence byte detected ? abort sequence detected ? lapd message type received ? c/r type ? the detection of fcs errors the user can control and monitor the actions of the lapd receiver via the following two registers. ? rx e3 lapd control register ? rx e3 lapd status register pmon bip-8 error count register?msb (address = 46h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 bip-8 error count?high byte ro ro ro ro ro ro ro ro pmon bip-8 error count register?lsb (address = 46h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 bip-8 error count?low byte ro ro ro ro ro ro ro ro
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 244 operation of the lapd receiver the lapd receiver, once enabled, will begin searching for the boundaries of the incoming lapd message. the lapd message frame boundaries are delineated via the ?flag sequence? octets (7eh), as depicted below in figure 66. where: flag sequence = 7eh sapi + c/r + ea = 3ch or 3eh tei + ea = 01h control = 03h the 16 bit fcs is calculated using crc-16, x 16 + x 12 + x 5 + 1 figure 66. lapd message frame format enabling and configuring the lapd receiver before the lapd receiver can begin to receive and process incoming lapd message frames, the user must do two things. flag sequence (8 bits) sapi (6-bits) c/r ea tei (7 bits) ea control (8 bits) 76 or 82 bytes of information (pmdl message) fcs?msb fcs?lsb flag sequence (8 bits)
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 245 1. he/she must specify which byte-field, within each e3 frame, will be carrying the comprising octets of the lapd message frame, and 2. he/she must enable the lapd receiver. each of these steps are discussed in detail, below. 1. specifying which byte-field, within each e3 frame, will be carrying the lapd message frame. the lapd receiver can receive the lapd message frame octets via either the gc byte-field or the nr byte-field, within each incoming e3 frame. the user makes this selection by writing the appropriate bit to bit 1 (dl from nr) within the rx e3 lapd control register, as depicted below. writing a ?0? to this bit-field causes the lapd receiver to read in the octets from the gc byte-field of each e3 frame, and with these octets; reassembling the lapd message frame. writing a ?1? to this bit-field causes the lapd receive to receive the lapd message frame octets from the nr byte-field of each e3 frame. 2. enabling the lapd receiver the lapd receiver must be enabled before it can begin receiving and processing any lapd message frames. the lapd receiver can be enabled by writing a ?1? to bit 1 (rx lapd enable) of the rx e3 lapd control register, as indicated below. once the lapd receiver has been enabled, it will begin searching for the flag sequence octets (7eh), in either the gc or the nr byte-fields within each incoming e3 frame. when the lapd receiver finds the flag sequence byte, it rx e3 lapd control register (address = 26h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused dl from nr rxlapd enable ro ro ro ro ro ro r/w r/w 0 0 0 0 0 0 x x rx e3 lapd control register (address = 26h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused dl from nr rxlapd enable ro ro ro ro ro ro r/w r/w 0 0 0 0 0 0 x 1
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 246 will assert the ?flag present? bit (bit 0) within the rx e3 lapd status register, as depicted below. the receipt of the flag sequence octet can mean one of two things. 1. this flag sequence byte may be marking the beginning of an incoming lapd message frame. 2. the received flag sequence octet could be just one of many flag sequence octets that are transmitted via the e3 transport medium, during idle periods between the transmission of lapd message frames. the lapd receiver will negate the ?flag present? bit as soon as it has received an octet that is something other than the ?flag sequence? octet. once this happens, the lapd receiver should be receiving either octet #2 of the incoming lapd message, or an abort sequence (e.g., a string of seven or more consecutive ?1s?). if this next set of data is an abort sequence, then the lapd receiver will assert the rxabort bit (bit 6) within the ?rx e3 lapd status? register, as depicted below. however, if this next octet is octet #2 of an incoming lapd message frame, then the lapd receiver is beginning to receive a lapd message frame. as the lapd receiver receives this lapd message frame, it is reading in the lapd message frame octets, from either the gc or the nr byte-fields within each incoming e3 frame. secondly, it is reassembling these octets into a lapd message frame. once the lapd receiver has received the complete lapd message frame, then it will proceed to perform the fol- lowing five (5) steps. 1. pmdl message extraction the lapd receiver will extract out the pmdl message, from the ?newly received? lapd message frame. the lapd receiver will then write this pmdl message into the ?receive lapd message? buffer within the uni. note: as the lapd receiver is extracting the pmdl message, from the ?newly received? lapd message frame, the lapd receiver will also check the pmdl data for the occurrence of stuff bits (e.g., ?0s? that were inserted into rx e3 lapd status register (address = 27h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused rxabort rxlapdtype[1:0] rxcr type rxfcs error end of message flag present ro ro ro ro ro ro ro ro 0 0 x x x 0 0 1 rx e3 lapd status register (address = 27h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused rxabort rxlapdtype[1:0] rxcr type rxfcs error end of message flag present ro ro ro ro ro ro ro ro 0 1 x x x 0 0 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 247 the pmdl message by the ?far-end? lapd transmitter, in order to prevent this data from mimicking the flag sequence byte or an abort sequence), and remove them prior to writing the pmdl message into the ?receive lapd message? buffer. specifically, the lapd receiver will search through the pmdl message data and will remove any ?0? that immediately follows a string of 5 consecutive ?1s?. for information on how the lapd transmitter inserted these stuff bits, please see section 6.3.3.5. 1. fcs (frame check sequence) word verification the lapd receiver will compute the crc-16 value of the header octets and the pmdl message octets, within this lapd message frame and will compare it with the value of the two octets, residing in the fcs word-field of this lapd message frame. if the fcs value of the ?newly received? lapd message frame matches the ?located com- puted? crc-16 value, then the lapd receiver will conclude that it has received this lapd message frame in an ?error-free? fashion. however, if the fcs value does not match the ?locally-computed? crc-16 value, then the lapd receiver will con- clude that this lapd message frame is errored. the lapd receiver will indicate the results of this ?fcs verification process? by setting bit 2 (rx fcs error), within the ?rx e3 lapd status? register, to the appropriate value as tabulated below. note: the lapd receiver will extract and write the pmdl message into the ?receive lapd message? buffer inde- pendent of the results of fcs verification. hence, the user is urged to validate each pmdl message that he/she reads in from the ?receive lapd message? buffer, by first checking the state of this bit-field. 2. check and report the state of the c/r bit-field after the receiving the lapd message frame, the lapd receiver will check the state of the ?c/r? bit-field, within rx e3 lapd status register (address = 27h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused rxabort rxlapdtype[1:0] rxcr type rx fcs error end of message flag present ro ro ro ro ro ro ro ro table 28. the relationship between the contents of bit 2 (rx fcs error) within the ?rx e3 lapd status register? and the results of fcs verification. rx fcs error (bit 2) results of fcs verification 0 lapd message frame was received in an ?error-free? fashion 1 lapd message frame is errored
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 248 octet #2 of the lapd message frame header; and will reflect this value in bit 3 (rx cr type) of the ?rx e3 lapd status register, as depicted below. when this bit-field is ?0?, it means that this lapd message frame is originating from a customer installation. when this bit-field is ?1?, it means that this lapd message frame is originating from a network terminal. 3. identify the type of lapd message frame/pmdl message next the lapd receiver will check the value of the first octet, within the pmdl message field, of the lapd message frame. recall from section 6.3.3.5.2, that when operating the lapd transmitter, the user is required to write in a byte of a specific value into the first octet position within the transmit lapd message? buffer. the value of this byte corresponds to the type of lapd message frame/pmdl message that is to be transmitted to the ?far-end? lapd receiver. this ?message-type identification? octet is transported to the ?far-end? lapd receiver, along with the rest of the lapd message frame. from this ?message-type identification? octet, the lapd receiver will know the type and size of the ?newly received? pmdl message. the lapd receiver will then reflect this information in bits 4 and 5 (rxlapdtype[1:0]) within the ?rx e3 lapd status? register; as depicted below. table 30 presents the relationship between the contents of ?rxlapdtype[1:0]? and the type of message received by the lapd receiver. note: prior to reading in the pmdl message from the ?receive lapd message? buffer the user is urged to read the state of the ?rxlapdtype[1:0] bit-fields in order to determine the size of this message. 4. inform the local m p/external circuitry of the receipt of the new lapd message frame finally, after the lapd receiver has received and processed the ?newly received? lapd message frame (per steps rx e3 lapd status register (address = 27h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused rxabort rxlapdtype[1:0] rxcr type rx fcs error end of message flag present ro ro ro ro ro ro ro ro rx e3 lapd status register (address = 27h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused rxabort rxlapdtype[1:0] rxcr type rx fcs error end of mes- sage flag present ro ro ro ro ro ro ro ro table 29. the relationship between the contents of rxlapdtype[1:0] bit-fields and the pmdl message type/size rxlapdtype[1:0] pmdl message type pmdl message size 00 test signal identification 76 bytes 01 idle signal identification 76 bytes 10 cl path identification 76 bytes 11 itu-t path identification 82 bytes
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 249 1 through 4, as described above), it will inform the local m p that a lapd message frame has been received and is ready for ?user-system? handling. the lapd receiver will inform the local m p and external circuitry of this by: ? generating a ?lapd message frame received? interrupt to the local m p. the purpose of this interrupt is to let the local m p know that the ?receive lapd message? buffer contains a new pmdl message that needs to be read and processed. when the lapd receiver generates this interrupt, it will set bit 5 (lapd interrupt sta- tus) within the ?rx e3 framer interrupt status register-2? to ?1?, as depicted below. ? setting bit 1 (end of message) within the ?rx e3 lapd status? register, to ?1? as depicted below. rx e3 framer interrupt status register-2 (address = 13h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused ttb change interrupt status lapd interrupt status febe interrupt status ferf interrupt status bip-8 error interrupt status framing byte error interrupt status rx pld mis interrupt status ro rur rur rur rur rur rur rur 0 0 1 0 0 0 0 0 rx e3 lapd status register (address = 27h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused rxabort rxlapdtype[1:0] rxcr type rx fcs error end of message flag present ro ro ro ro ro ro ro ro
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 250 in summary, figure 67 presents a flow chart depicting how the lapd receiver works. figure 67. flow chart depicting the functionality of the lapd receiver 7.1.2.6 processing of the far-end-block error (febe) bit-fields whenever the receive e3 framer detects an error in an incoming e3 frame, via em byte verification, it will inform the ?near-end? transmit e3 framer of this fact. the ?near-end? transmit e3 framer will, in turn, notify the ?far-end? terminal (e.g., the source of the errored e3 frame) by transmitting an e3 frame, with the febe bit-field (within the ma byte) set to ?1?. start indicate whether the lapd receiver should retrieve the lapd message frame octets from the nr or gc byte-field, within each incoming e3 frame. enable the lapd receiver. the lapd receiver will begin searching for the flag sequence octet (7eh) in the ?selected? byte-field (e.g., nr or gc) of each incoming e3 frame. is flag sequence octet present? assert the ?flag present? bit-field within the ?rx e3 lapd status register (address = 27h). is non-flag sequence octet detected ? set the ?rxlapdtype[1:0] bit-fields to the appropriate value. continue to read in the lapd message frame octets is abort sequence detected? has the last byte of the lapd message frame been received? set the ?end of message? bit-field within the ?rxe3 lapd status register (address = 27h). unstuff the ?pmdl? portion of the lapd message frame. goto figure 67a. no a yes no yes no yes no yes compute ?frame check sequence (fcs)? value of incoming lapd message frame. compare ?locally-computed? fcs value with that contained within the newly received lapd message frames. do the two fcs values match? fcs error detected assert the ?rx fcs error? bit-field within the ?rx e3 lapd status register (address = 27h). generate the ?receive lapd message frame? interrupt. from figure 67 end a no yes
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 251 if the receive e3 framer receives any e3 frame, with the febe bit-field set to ?1?, then it will do the following. ? it will generate a ?febe event? interrupt to the local m p. hence the receive e3 framer will set bit 4 (febe interrupt status) within the ?rx e3 framer interrupt status register-2?, as depicted below. ? increment the ?pmon received febe event count register?msb/lsb, which is located at 44h and 45h in the uni address space. the byte-format of these registers are presented below. the user can determine the total number of febe event (e.g., e3 frames that have been received with the febe bit-field set to ?1?) that have occurred since the last read of this register. this register is reset upon read. 7.1.2.7 trail trace buffers the XR-T7234 e3 uni device contains 16 bytes worth of ?transmit? trail trace buffers, and 16 bytes worth of ?receive? trail trace buffer. the role of the ?receive? trail trace buffers is described below. the role of the ?transmit? trail buffers are described in section 6.3.3.4. the XR-T7234 e3 uni device contains 16 ?receive trail trace buffer? registers (e.g., rx ttb-0 through rx ttb-15). the purpose of these registers are to receive and store the incoming ?trail access point identifier? from the ?far- end? transmitting terminal. the ?near-end? receiving terminal will use this information to verify that it is still receiving data from its intended transmitter. the specific use of these registers follows. for ?trail trace buffer? purposes, the ?far-end? transmit e3 framer will group 16 consecutive e3 frames into a ?trail trace buffer? super-frame. when the ?far-end? transmit e3 framer is generating the first e3 frame, within a rx e3 framer interrupt status register-2 (address = 13h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused ttb change interrupt status lapd interrupt status febe interrupt status ferf interrupt status bip-8 error interrupt status framing byte error interrupt status rx pld mis interrupt status ro rur rur rur rur rur rur rur 0 0 0 1 0 0 0 0 pmon received febe event count register?msb bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 received febe event count?high byte ro ro ro ro ro ro ro ro pmon received febe event count register?lsb bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 received febe event count?low byte ro ro ro ro ro ro ro ro
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 252 ?trail trace buffer? super-frame, it will insert the value [1, c6, c5, c4, c3, c2, c1, c0], into the tr byte-field of this ?outbound? e3 frame. the remaining 15 tr byte-fields (within this ?trail trace buffer? super-frame) will consists of ascii characters that are required for the e.164 numbering format. when the ?near-end? receiver e3 framer receives an e3 frame, containing a value in the tr byte-field that has a ?1? in the msb position, then it (the receive e3 framer) will write this value into the rx ttb-0 register (address = 16h). once this occurs, the receive e3 framer will notify the local m p of this ?new? incoming trail trace buffer message by generating the ?change in trail trace buffer message? interrupt. the receive e3 framer will also set bit 6 (ttb change interrupt status) within the ?rx e3 framer interrupt status?register-2?; as depicted below. the contents of the tr byte-field, in the very next e3 frame will be written into the rx ttb-1 register (address = 17h), and so on until all 16 bytes have been received. note: 1. anytime the receive e3 framer receives an e3 frame that contains an octet in the tr byte-field, with a ?1? in the msb (most significant bit) position; then the receive e3 framer will do the following. ? it will write the contents of the tr byte-field (in this e3 frame) into the rx ttb-0 register. ? it will generate the ?change in trail trace buffer message? interrupt the receive e3 framer will do these things independent of the number of e3 frames that have been received since the occurrence of the last ?occurrence? of the ?change in trail trace buffer message? interrupt. hence, the user, when writing data into the tx ttb registers, must take care to insure that only tx ttb-0 contains an octet with a ?1? in the msb position. all remaining tx ttb registers (e.g., tx ttb-1 through tx ttb-15) must contain octets with a ?0? in the msb position. 2. the uni will not verify the crc-7 value that is written into the rx ttb-0 register. it is up to the user?s system hardware and/or software to perform this verification. 7.1.2.8 extracting the e3 overhead bytes via the serial output port the receive e3 framer block also consists of the ?rxoh? serial output port. this serial output port consists of the following output pins: ? rxoh ? rxohclk rx e3 framer interrupt status register-2 (address = 13h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused ttb change interrupt status lapd interrupt status febe interrupt status ferf interrupt status bip-8 error interrupt status framing byte error interrupt status rx pld mis interrupt status ro rur rur rur rur rur rur rur 0 1 0 0 0 0 0 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 253 ? rxohframe the receive e3 framer will serially output the oh bytes (of the incoming e3 frame) via the ?rxoh? output pin. this output signal will be updated on the rising edge of the rxohclk clock signal. finally, the rxohframe output pin will pulse ?high? when the first bit of the fa1 octet, within an e3 frame is being output at the rxoh output pin. the order in which these oh bytes are output (via the rxoh pin) is in accordance with that in figure 61. figure 68 presents a timing diagram that illustrates the behavior of the rxoh serial output port signals. figure 68. illustration of the rxoh serial output port signals 7.1.2.9 receive e3 framer interrupt conditions the receive e3 framer can generate an interrupt request upon any of the following conditions. ? change in oof (out of frame) condition ? change in lof (loss of frame) condition ? change in los (loss of signal) condition ? change in ais status ? detection of bip-8 error ? change in ferf (far-end-receive failure) condition ? change in frame alignment ? receipt of new trail trace buffer message ? payload type mismatch change ? receipt of a new lapd message frame if one of these conditions occur, and if that particular condition has been enabled for interrupt generation, the when the local m p reads the uni interrupt status register, as shown below; it should read ?0xx1xxxxb? (where the -b suf- rxohframe rxohclk rxoh t35 t36 t37 t34 fa1[7] fa1[6] fa1[5] fa1[4] fa1[3]
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 254 fix denotes a binary expression, and the ?x? denotes a ?don?t care? value.) at this point, the local m p will have determined that the receive e3 framer block is the source of the interrupt, and that the interrupt service routine should branch accordingly. in order to accomplish this, the local m p should now proceed to read one or both of the following registers. ? rx e3 framer interrupt status register-1 (address = 12h) ? rx e3 framer interrupt status register-2 (address = 13h) the role of the bits, within each of these register, to interrupt processing, are described below. 7.1.2.9.1 ?change in oof condition? interrupt the receive e3 framer will generate the ?change in oof condition? interrupt in response to either of the following two occurrences. 1. whenever the receive e3 framer transitions from the ?in-frame? state to the ?oof condition? state, within the ?e3 framing acquisition/maintenance? algorithm (per figure 60). 2. whenever the receive e3 framer transitions from the ?oof condition? state, back into the ?in frame? state, within the ?e3 framing acquisition/maintenance? algorithm. recall from the discussion in section 7.1.2.2, that the receive e3 framer will transition from the ?in-frame? state into the ?oof condition? state, if the receive e3 framer detects errors in the framing alignment bits (fa1 and fa2) for four (4) consecutive e3 frames. additionally, the receive e3 framer will transition from the ?oof condition? state to the ?in-frame? state, if the receive e3 framer is able to properly locate the frame alignment bytes (fa1 and fa2) for two consecutive e3 frames. when the receive e3 framer generates the ?change in oof condition? interrupt, then it will assert bit 3 (oof interrupt status) within the rx e3 framer interrupt status register-1? (address = 12h); as depicted below. this ?reset upon read? bit-field will be set to ?1? if a ?change in oof condition? has occurred since the last read of uni interrupt status register (address = 05h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused one sec interrupt status tx e3 framer interrupt status rx e3 framer interrupt status tx cp interrupt status rx cp interrupt status tx utopia interrupt status rx utopia interrupt status ro rur rur rur rur rur rur rur 0 x x 1 x x x x rx e3 framer interrupt status register -1 (address = 12h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused cofa interrupt status oof interrupt status lof interrupt status los interrupt status ais interrupt status ro ro ro rur rur rur rur rur 0 0 0 x 1 x x x
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 255 this register. the user can enable or disable the ?change in oof condition? interrupt by writing the appropriate value to bit 3 (oof interrupt enable) within the ?rx e3 framer interrupt enable register-1?, as depicted below. writing a ?0? to this ?read/write? bit-field disables the ?change in oof condition? interrupt. writing a ?1? to this bit- field enables the ?change in oof condition? interrupt. 7.1.2.9.2 ?change in lof condition? interrupt the receive e3 framer will generate the ?change in lof condition? interrupt in response to either of the following two occurrences. 1. whenever the receive e3 framer transitions from the ?oof condition? state into the ?lof condition? state, within the ?e3 framing acquisition/maintenance? algorithm (per figure 60). 2. whenever the receive e3 framer transitions from the ?fa1, fa2 octet verification? state to the ?in-frame? state, within the ?e3 framing acquisition/maintenance? algorithm (per figure 60). recall from the discussion in section 7.1.2.2.1, that the receive e3 framer will transition from the ?oof condition? state into the ?lof condition? state, if the receive e3 framer remains in the ?oof condition? state for a ?user- selectable? amount of time (either 1 ms or 3 ms) and is unable to regain the ?in-frame? state. additionally, the receive e3 framer will transition from the ?fa1, fa2 octet verification? state to the ?in-frame? state, if the receive e3 framer is able to properly locate the frame alignment bytes (fa1 and fa2) for two consecutive e3 frames. when the receive e3 framer generates the ?change in lof condition? interrupt, then it will assert bit 2 (lof interrupt status) within the rx e3 framer interrupt status register-1? (address = 12h); as depicted below. this ?reset upon read? bit-field will be set to ?1? if a ?change in lof condition? interrupt has occurred since the last read of this register. the user can enable or disable the ?change in lof condition? interrupt by writing the appropriate value to bit 2 rx e3 framer interrupt enable register-1 (address = 12h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused cofa interrupt enable oof interrupt enable lof interrupt enable los interrupt enable ais interrupt enable ro ro ro r/w r/w r/w r/w r/w rx e3 framer interrupt status register-1 (address = 12h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused cofa interrupt status oof interrupt status lof interrupt status los interrupt status ais interrupt status ro ro ro rur rur rur rur rur 0 0 0 x x 1 x x
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 256 (lof interrupt enable) within the ?rx e3 framer interrupt enable register-1? as depicted below. writing a ?0? to this ?read/write? bit-field disables the ?change in lof condition? interrupt. writing a ?1? to this bit-field enables the ?change in lof condition? interrupt. 7.1.2.9.3 ?change in los condition? interrupt the receive e3 framer will generate the ?change in los condition? interrupt in response to either of the following two occurrences. 1. whenever the receive e3 framer detects a string of 32 consecutive ?0s? in the incoming e3 frame data, via the rxpos and rxneg input pins. 2. whenever the receive e3 framer negates the los condition. recall, from section 7.1.2.3.1, that the receive e3 framer will negate the los condition upon the detection of a string a 32 bits that does not contain a string of 4 consecutive 0?s. when the receive e3 framer generates the ?change in los condition? interrupt, then it will assert bit 1 (los interrupt status) within the rx e3 framer interrupt status register-1? (address = 12h); as depicted below. this ?reset upon read? bit-field will be set to ?1? if a ?change in los condition? interrupt has occurred since the last read of this register. the user can disable or enable the ?change in los condition? interrupt by writing the appropriate value to bit 1 rx e3 framer interrupt enable register-1 (address = 12h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused cofa interrupt enable oof interrupt enable lof interrupt enable los interrupt enable ais interrupt enable ro ro ro r/w r/w r/w r/w r/w rx e3 framer interrupt status register-1 (address = 12h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused cofa interrupt status oof interrupt status lof interrupt status los interrupt status ais interrupt status ro ro ro rur rur rur rur rur 0 0 0 x x x 1 x
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 257 (los interrupt enable) within the ?rx e3 framer interrupt enable register-1? as depicted below. writing a ?0? to this ?read/write? bit-field disables the ?change in los condition? interrupt. writing a ?1? to this bit- field enables the ?change in los condition? interrupt. 7.1.2.9.4 ?change in ais status? interrupt the receive e3 framer will generate the ?change in ais condition? interrupt in response to either of the following two occurrences. 1. whenever the receive e3 framer detects 7 or fewer zeros in the incoming e3 frame datastream, for two con- secutive e3 frame periods. 2. whenever the receive e3 framer negates the ?ais condition?. recall, from section 7.1.2.3.2, that the receive e3 framer will negate the ais condition upon the detection two consecutive e3 frames, that each contain 8 or more zeros. when the receive e3 framer generates the ?change in ais condition? interrupt, then it will assert bit 0 (ais interrupt status) within the rx e3 framer interrupt status register-1 (address = 12h); as depicted below. this ?reset upon read? bit-field will be set to ?1? if a ?change in ais condition? interrupt has occurred since the last read of this register. the user can disable or enable the ?change in ais condition? interrupt by writing the appropriate value to bit 0 (ais interrupt enable) within the ?rx e3 framer interrupt enable register-1? as depicted below. rx e3 framer interrupt enable register-1 (address = 10h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused cofa interrupt enable oof interrupt enable lof interrupt enable los interrupt enable ais interrupt enable ro ro ro r/w r/w r/w r/w r/w rx e3 framer interrupt status register-1 (address = 12h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused cofa interrupt status oof interrupt status lof interrupt status los interrupt status ais interrupt status ro ro ro rur rur rur rur rur 0 0 0 x x x x 1 rx e3 framer interrupt enable register-1 (address = 10h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused cofa interrupt enable oof interrupt enable lof interrupt enable los interrupt enable ais interrupt enable ro ro ro r/w r/w r/w r/w r/w
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 258 writing a ?0? to this ?read/write? bit-field disables the ?change in ais condition? interrupt. writing a ?1? to this bit-field enables the ?change in ais condition? interrupt. 7.1.2.9.5 the ?bip-8 error? interrupt the receive e3 framer will generate the ?bip-8 error? interrupt upon detection of an errored incoming e3 frame. recall from section 7.1.2.4, that the receive e3 framer computes the bip-8 value, based upon all 537 octets, within a given incoming e3 framer. afterwards, the receive e3 framer will compare its ?locally computed? bip-8 value with the contents of the em byte-field, in the very next incoming e3 frame. if the ?locally computed? bip-8 value match that received in the em byte of incoming e3 frame, then the receive e3 framer will conclude that this e3 frame was received in an ?error-free? manner. however, if the ?locally computed? bip-8 value does not match that received in the em byte of the incoming e3 frame, then the receive e3 framer will conclude the this newly received e3 frame is errored. when the receive e3 framer generates the ?bip-8 error? interrupt, then it will assert bit 2 (bip-8 error) within the rx e3 framer interrupt status register-1? (address = 13h); as depicted below. this ?reset upon read? bit-field will be set to ?1? if the ?bip-8 error? interrupt has occurred since the last read of this register. the user can disable or enable the ?bip-8 error? interrupt by writing the appropriate value to bit 2 (bip-8 interrupt enable) within the ?rx e3 framer interrupt enable register-2?, as depicted below. writing a ?0? to this ?read/write? bit-field disables the ?bip-8 error? interrupt. writing a ?1? to this bit-field enables the ?bip-8 error? interrupt. 7.1.2.9.6 ?change in ferf condition? interrupt the receive e3 framer will generate the ?change in ferf condition? interrupt in response to either of the following two occurrences. 1. whenever the receive e3 framer declares a ?ferf? condition rx e3 framer interrupt status register-2 (address = 13h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused ttb change interrupt status lapd interrupt status febe interrupt status ferf interrupt status bip-8 interrupt status framing bit error interrupt status rx pld mis interrupt status ro rur rur rur rur rur rur rur 0 x x x x 1 x x rx e3 framer interrupt enable register-2 (address = 11h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused ttb change interrupt enable lapd interrupt enable febe interrupt enable ferf interrupt enable bip-8 interrupt enable framing bit error interrupt enable rx pld mis interrupt enable ro r/w r/w r/w r/w r/w r/w r/w
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 259 2. whenever the receive e3 framer negates the ?ferf? condition recall from section 7.1.2.3.3, the receive e3 framer will declare a ?ferf (far-end-receive failure)? condition if it receives a ?user-selectable? number of incoming e3 frames, with the ?ferf? bit set to ?1?. this ?user selectable? number of e3 frames is either 3 or 5. likewise, the receive e3 framer will negate the ?ferf? condition, if it receives the ?user-selectable? number of incoming e3 frames, with the ?ferf? bit set to ?0?. once again, this ?user-selectable? number of e3 frames is either 3 or 5. when the receive e3 framer generates the ?change in ferf condition? interrupt, then it will assert bit 3 (ferf interrupt status) within the rx e3 framer interrupt status register-2 (address = 13h); as depicted below. this ?reset upon read? bit-field will be set to ?1? if a ?change in ferf condition? interrupt has occurred since the last read of this register. the user can disable or enable the ?change in ferf condition? interrupt by writing the appropriate value to bit 3 (ferf interrupt enable) within the ?rx e3 framer interrupt enable register-2? as depicted below. writing a ?0? to this ?read/write? bit-field disables the ?change in ferf condition? interrupt. writing a ?1? to this bit-field enables the ?change in ferf condition? interrupt. 7.1.2.9.7 ?change of frame alignment? interrupt the receive e3 framer will generate the ?change of frame alignment? interrupt if it has detected a change in frame alignment, in the incoming e3 frames. note: this interrupt will typically be accompanied with the occurrences of the following types of interrupts: ? framing bit error ? change in oof status ? change in lof status rx e3 framer interrupt status register-2 (address = 13h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused ttb change interrupt status lapd interrupt status febe interrupt status ferf interrupt status bip-8 interrupt status framing bit error interrupt status rx pld mis interrupt status ro rur rur rur rur rur rur rur 0 x x x 1 x x x rx e3 framer interrupt enable register-2 (address = 11h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused ttb change interrupt enable lapd interrupt enable febe interrupt enable ferf interrupt enable bip-8 interrupt enable framing bit error interrupt enable rx pld mis interrupt enable ro r/w r/w r/w r/w r/w r/w r/w
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 260 when the receive e3 framer generates the ?change in frame alignment? interrupt, then it will assert bit 4 (cofa interrupt status) within the rx e3 framer interrupt status register-1 (address = 12h); as depicted below. this ?reset upon read? bit-field will be set to ?1? if the ?change of frame alignment? interrupt has occurred since the last read of this register. the user can disable or enable the ?change of frame alignment? interrupt by writing the appropriate value to bit 4 (cofa interrupt enable) within the ?rx e3 framer interrupt enable register-1? as depicted below. writing a ?0? to this ?read/write? bit-field disables the ?change of framing alignment? interrupt. writing a ?1? to this bit-field enables the ?change of framing alignment? interrupt. 7.1.2.9.8 ?receipt of new trail trace buffer message? interrupt the receive e3 framer will generate the ?receipt of new trail trace buffer message? interrupt upon detection of a tr byte, (within an incoming e3 frame) that contains a ?0? in the msb position. recall from section 7.1.2.7, that when the receive e3 framer receives an e3 frame, containing a tr byte of the form ?0xxxxxxx?, then the receive e3 framer will write this value into the rx ttb-0 register; and will generate the ?receipt of new trail trace buffer message? interrupt. the purpose of this interrupt is to notify the local m p that the receive e3 framer is in the process of receiving a new trail trace buffer message, from the ?far-end? transmitter. rx e3 framer interrupt status register-1 (address = 12h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused cofa interrupt status oof interrupt status lof interrupt status los interrupt status ais interrupt status ro ro ro rur rur rur rur rur 0 0 0 1 x x x x rx e3 framer interrupt enable register-1 (address = 10h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused cofa interrupt enable oof interrupt enable lof interrupt enable los interrupt enable ais interrupt enable ro ro ro r/w r/w r/w r/w r/w
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 261 when the receive e3 framer generates the ?new trail trace buffer message? interrupt, then it will assert bit 6 (ttb change interrupt status) within the rx e3 framer interrupt status register-2 (address = 13h); as depicted below. this ?reset upon read? bit-field will be set to ?1? if a ?receipt of new trail trace buffer message? interrupt has occurred since the last read of this register. the user can disable or enable the ?receipt of new trail trace buffer message? interrupt by writing the appropriate value to bit 6 (ttb change interrupt enable) within the ?rx e3 framer interrupt enable register-2? as depicted below . writing a ?0? to this ?read/write? bit-field disables the ?receipt of new trail trace buffer message? interrupt. writing a ?1? to this bit-field enables this interrupt. 7.1.2.9.9 ?payload type mismatch? interrupt the receive e3 framer will generate the ?payload type mismatch? interrupt, when it detects that the values, within the payload type bit-fields of the incoming e3 frame, are different from that which is expected by the receive e3 framer. recall from section 6.3.2.1.4, that the ma byte (within the e3 frame) contains three bit-fields that are used to identify the ?kind of data? that is being transported in the 530 bytes of e3 frame payload data. in this particular device, the e3 frames will typically be carrying atm cell data, in their payload bytes. hence, the payload type value, for these e3 frame will typically be ?010?. the user can specify the ?payload type? value that the receive e3 framer should expect from the incoming e3 frames, by writing this into bits 2?0, within the ?rx e3 configuration & status? register (address = 0eh); as depicted below. rx e3 framer interrupt status register-2 (address = 13h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused ttb change interrupt status lapd interrupt status febe interrupt status ferf interrupt status bip-8 interrupt status framing bit error interrupt status rx pld mis interrupt status ro rur rur rur rur rur rur rur 0 1 x x x x x x rx e3 framer interrupt enable register-2 (address = 11h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused ttb change interrupt enable lapd interrupt enable febe interrupt enable ferf interrupt enable bip-8 interrupt enable framing bit error interrupt enable rx pld mis interrupt enable ro r/w r/w r/w r/w r/w r/w r/w
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 262 if the receive e3 framer starts to receive e3 frames that contain a different ?payload type? than what is written into the ?rx e3 configuration and status? register-1; then the receive e3 framer will generate the ?payload type mis- match? interrupt. the purpose of this interrupt is to let the local m p know that the ?near-end? terminal is now receiv- ing e3 frames that are carrying a different type of data (in its payload bytes), than that of previous e3 frames. when the receive e3 framer generates the ?payload type mismatch? interrupt, then it will assert bit 0 (rx pld mis. interrupt status) within the rx e3 framer interrupt status register-2 (address = 13h); as depicted below. this ?reset upon read? bit-field will be set to ?1? if a ?payload type mismatch? interrupt has occurred since the last read of this register. the user can disable or enable the ?payload type mismatch? interrupt by writing the appropriate value to bit 0 (rx pld mis. interrupt enable) within the ?rx e3 framer interrupt enable register-2? as depicted below. writing a ?0? to this ?read/write? bit-field disables the ?payload type mismatch? interrupt. writing a ?1? to this bit-field enables this interrupt. rx e3 configuration and status register-1 (address = 0eh) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rxpldtype[2:0] rxferf algo rx tmark algo rxpldexp[2:0] ro ro ro r/w r/w r/w r/w r/w 0 0 0 1 0 0 0 0 rx e3 framer interrupt status register-2 (address = 13h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused ttb change interrupt status lapd interrupt status febe interrupt status ferf interrupt status bip-8 interrupt status framing bit error interrupt status rx pld mis interrupt status ro rur rur rur rur rur rur rur 0 x x x x x x 1 rx e3 framer interrupt enable register-2 (address = 11h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused ttb change interrupt enable lapd interrupt enable febe interrupt enable ferf interrupt enable bip-8 interrupt enable framing bit error interrupt enable rx pld mis interrupt enable ro r/w r/w r/w r/w r/w r/w r/w
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 263 7.1.2.9.10 ?receipt of new lapd message frame? interrupt the receive e3 framer will generate the ?receipt of new lapd message frame? interrupt, when the lapd receiver has received a complete lapd message frame, from the ?far-end? lapd transmitter. the purpose of this interrupt is to inform the local m p that the lapd receiver has received a lapd message, from the ?far-end? lapd transmitter, and that the ?receive lapd message buffer? contains a pmdl message that is ready to be read and processed by the m p. when the receive e3 framer generates the ?receipt of new lapd message? interrupt, then it will assert bit 5 (lapd interrupt status) within the rx e3 framer interrupt status register-2 (address = 13h); as depicted below. this ?reset upon read? bit-field will be set to ?1? if a ?receipt of new lapd message? interrupt has occurred since the last read of this register. the user can disable or enable the ?receipt of new lapd message? interrupt by writing the appropriate value to bit 5 (lapd interrupt enable) within the ?rx e3 framer interrupt enable register-2?, as depicted below. writing a ?0? to this ?read/write? bit-field disables the ?receipt of new lapd message? interrupt. writing a ?1? to this bit-field enables this interrupt. 7.1.2.9.11 febe interrupt the receive e3 framer will generate the ?far-end-block-error? (febe) interrupt, anytime it detects a ?1? in the febe bit-field, within an incoming e3 frame. the purpose of this interrupt is to let the local m p know that the ?far-end? receive e3 framer is receiving errored e3 frames, from the ?near-end? transmit e3 framer. rx e3 framer interrupt status register-2 (address = 13h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused ttb change interrupt status lapd interrupt status febe interrupt status ferf interrupt status bip-8 interrupt status framing bit error interrupt status rx pld mis interrupt status ro rur rur rur rur rur rur rur 0 x 1 x x x x x rx e3 framer interrupt enable register-2 (address = 11h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused ttb change interrupt enable lapd interrupt enable febe interrupt enable ferf interrupt enable bip-8 interrupt enable framing bit error interrupt enable rx pld mis interrupt enable ro r/w r/w r/w r/w r/w r/w r/w
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 264 when the receive e3 framer generates the ?febe? interrupt, then it will assert bit 4 (febe interrupt status) within the rx e3 framer interrupt status register-2 (address = 13h); as depicted below. this ?reset upon read? bit-field will be set to ?1? if the ?febe? interrupt has occurred since the last read of this register. the user can disable or enable the ?febe? interrupt by writing the appropriate value to bit 4 (febe interrupt enable) within the ?rx e3 framer interrupt enable register-2? as depicted below. writing a ?0? to this ?read/write? bit-field disables the ?febe? interrupt. writing a ?1? to this bit-field enables the ?febe? interrupt. 7.1.2.9.12 framing byte error interrupt the receive e3 framer will generate the ?framing byte error? interrupt upon detection of an error in either the fa1 or fa2 framing octets, within an incoming e3 frame. recall from section 7.1.2.2, that the purpose of the fa1 and fa2 octets are to allow the receive e3 framer to locate the boundaries of each incoming e3 frames. the fa1 and fa2 octets are assigned the value of f6h and 28h, respectively. the purpose of this interrupt is to let the local m p know that the ?near-end? receive e3 framer may be experienc- ing the early stages of an ?oof (out-of-frame)? condition. rx e3 framer interrupt status register-2 (address = 13h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused ttb change interrupt status lapd interrupt status febe interrupt status ferf interrupt status bip-8 interrupt status framing bit error interrupt status rx pld mis interrupt status ro rur rur rur rur rur rur rur 0 x x 1 x x x x rx e3 framer interrupt enable register-2 (address = 11h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused ttb change interrupt enable lapd interrupt enable febe interrupt enable ferf interrupt enable bip-8 interrupt enable framing bit error interrupt enable rx pld mis interrupt enable ro r/w r/w r/w r/w r/w r/w r/w
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 265 when the receive e3 framer generates the ?framing byte error? interrupt, then it will assert bit 1 (framing byte error interrupt status) within the rx e3 framer interrupt status register-2 (address = 13h); as depicted below. this ?reset upon read? bit-field will be set to ?1? if the ?framing byte error? interrupt has occurred since the last read of this register. the user can disable or enable the ?framing byte error? interrupt by writing the appropriate value to bit 1 (framing byte error interrupt enable) within the ?rx e3 framer interrupt enable register-2? as depicted below. writing a ?0? to this ?read/write? bit-field disables the ?framing byte error? interrupt. writing a ?1? to this bit-field enables the ?framing byte error? interrupt. 7.2 receive cell processor 7.2.1 brief description of the receive cell processor the receive cell processor receives unframed atm cell data from the receive e3 framer. the receive cell processor will then perform the following operations on this data. ? cell delineation ? hec byte verification ? idle cell filtering (optional) ? user/oam cell filtering (optional) ? cell-payload de-scrambling (optional) the receive cell processor will also output the gfc nibble value of each incoming cell, via the ?gfc nibble-field? serial output port. rx e3 framer interrupt status register-2 (address = 13h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused ttb change interrupt status lapd interrupt status febe interrupt status ferf interrupt status bip-8 interrupt status framing byte error interrupt status rx pld mis interrupt status ro rur rur rur rur rur rur rur 0 x x x x x 1 x rx e3 framer interrupt enable register-2 (address = 11h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused ttb change interrupt enable lapd interrupt enable febe interrupt enable ferf interrupt enable bip-8 interrupt enable framing byte error interrupt enable rx pld mis interrupt enable ro r/w r/w r/w r/w r/w r/w r/w
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 266 figure 69 presents a simple block diagram of the receive cell processor block along with its external pins. figure 69. simple illustration of the receive cell processor, with associated pins 7.2.2 functional description of receive cell processor the receive cell processor receives unframed atm cell data from the receive e3 framer. once the receive cell processor receives this information then it will proceed to perform the following functions. ? cell delineation ? hec byte verification (header error detection/correction) ? idle cell filtering ? user cell filtering ? cell payload de-scrambling receive cell processor rxcellrxed rxgfcclk rxgfcmsb rxgfc from receive e3 framer to receive utopia interface block rxlcd
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 267 each of these functions are discussed in detail below. figure 70 presents a functional block diagram of the receive cell processor. figure 70. functional block diagram of the receive cell processor 6-byte buffer hec crc calculator error position calculator idle & oam cell detector oam memory configuration and status registers de-scrambler data path check controller delineation and error correction bufclk bufdat[3:0] rxcoseten hecerr rxgfcclk rxgfcstart rxgfc rfifodat[7:0] to rx utopia rusoc rfifowrclk rfifowrenb csb* writeb* readb* rxcpregsel databush[7:0] databusl[7:0] rxcpint corren rdpchkpat rdpchken oam extract icdiscard hecerrignore corrthresh[1:0] rxcoseten de-scren icfound oamfound cellcount[5:0] oam write oam cycle oamdata[7:0] ready de-scramdata[7:0]
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 268 7.2.2.1 cell delineation the receive cell processor is receiving unframed cell data from the receive e3 framer. therefore, the receive cell processor will have to use the ?hec byte? cell-delineation algorithm in order to locate the boundaries of these cells. the hec byte cell delineation algorithm contains three states: hunt, presync, and sync, as depicted in the state machine diagram in figure 71. each of these states are discussed below. figure 71. cell delineation algorithm employed by the receive cell processor the hunt state when the uni chip is first powered up, the receive cell processor will initially be operating in the ?hunt? state. while the receive cell processor is operating in the ?hunt? state, it has no knowledge of the location of the boundaries of the incoming cells. in the hunt state, the receive cell processor is searching through the incoming (?unframed?) cell data-stream for a possible valid cell header pattern (e.g., one that does not produce a hec byte error). therefore, while in this state, the receive cell processor will read in five octets of the data that it receives from the receive e3 framer. the receive cell processor will then compute a ?hec byte? value based upon the first four of these five octets. the receive cell processor will then compare this computed value with that of the 5th ?read-in? octet. if the two values are not the same, then the receive cell processor will increment its sampling set (of the 5 bytes) by one bit, and repeat the above-process with this new set of ?candidate? header bytes. in other words, the receive cell processor make its next selection of the five ?sample? octets, 53 bytes and 1 bit later. if the receive cell processor comes across a set of five octets, that are such that the computed hec byte value does match the 5th (read in) octet, then the receive cell processor will transition to the presync state. the pre-sync state the receive cell processor will transition from the ?hunt? state to the ?presync? state; when it has located an ?apparently? valid set of cell header bytes. however, it is possible that the receive cell processor is being ?fooled? by user data that mimics the cell header byte pattern. therefore, further evaluation is required in order to confirm that this set of octets are truly valid cell header bytes. the purpose of the ?pre-sync? state is to facilitate this ?fur- ther evaluation?. hunt presync sync correct hec incorrect hec delta consecutive correct hec at 53 byte intervals alpha consecutive incorrect hec
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 269 when the receive cell processor is operating in the pre-sync state, it will then begin to sample 5 ?candidate header bytes? at 53 byte intervals. during this sampling process, the receive cell processor will compute and com- pare its newly computed ?hec byte value? with that of the fifth (read-in) octet. if the receive cell processor, while operating in the pre-sync state, comes across a single invalid cell header byte pattern, then the receive cell processor will transition back to the ?hunt? state. however, if the receive cell processor detects ?delta? consec- utive valid cell byte headers, then it will transition into the sync state. the sync state the receive cell processor will notify the local mp (and external circuitry) of its transition to the sync state by ? generating a ?change of lcd (loss of cell delineation) state? interrupt. when the receive cell processor generates the ?change in lcd condition? interrupt, it will also set bit 1 (lcd interrupt status) within the ?rx cp interrupt status? register, as depicted below. ? negating the rxlcd output pin (e.g., toggling it ?low?); and ? setting bit 7 (rx lcd) within the rx cp configuration register to ?0?. when the receive cell processor is operating in the sync state, it is assumed to be properly delineating the atm cells. once the receive cell processor is running the ?sync? state, it will tolerate some sporadic errors in the cell header bytes and, in some cases, even attempt to correct them. however, the occurrence of ?alpha? consecutive cells with header byte errors (single or multi-bit), will cause the receive cell processor to return to the ?hunt? state. the receive cell processor will notify the external circuitry that it is not properly delineating cells by doing the following. ? generating a ?change in lcd state? interrupt ? asserting the rxlcd output pin (e.g., toggling it ?high?). rx cp interrupt status register (address = 61h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused received oam cell interrupt status lcd interrupt status hec error interrupt status ro ro ro ro ro rur rur rur 0 0 0 0 0 0 1 x rx cp configuration register (address = 5eh) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rxlcd rdpchk pattern rdpchk pattern enable idle cell discard oam check bit de- scramble enable rxcoset enable hec error ignore ro r/w r/w r/w r/w r/w r/w r/w 1 x x x x x x x
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 270 ? setting bit 7 (rx lcd) within the rx cp configuration register to ?0?, as depicted below. the remaining discussion of the receive cell processor, within this data sheet, presumes that it (the receive cell processor) is operating in the ?sync? state and is properly delineating cells. the overall cell filtering/processing approach within the receive cell processor block once the receive cell processor is properly delineating cells then it will proceed to route these cells through a series of ?filters?; prior to allowing these cells to written to the rxfifo within the receive utopia interface block. the sequence of filtering/processing that each cell must go through is listed below in sequential order. ? hec byte verification ? idle cell filtering ? user cell filtering ? cell payload de-scrambling ? inserting of the ?data path integrity check? pattern into the 5th octet of each cell. this sequence of processing; (within the receive cell processor) is also illustrated in figure 72. each of these ?filtering/processing? steps (within the receive cell processor) are discussed in detail below. figure 72. illustration of overall cell filtering/processing procedure that occurs within the receive cell processor block 7.2.2.2 hec byte verification once the receive cell processor is properly delineating cells, the receive cell processor will perform ?hec byte verification? of incoming cell data from the receive e3 framer, in order to protect against mis-routed or mis-inserted cells. in performing hec byte verification the receive cell processor will take the first four bytes of each cell (e.g., the header bytes) and independently compute its own value for the hec byte. afterwards, the receive cell proces- sor will compare its value of the hec byte with the fifth octet that it has received from the receive e3 framer. if the two hec byte values match then the receive cell processor will retain this cell for further processing. however, if the receive cell processor detects errors in the header bytes of a cell, then the receive cell processor will call up and employ the ?hec byte error correction/detection? algorithm (see below). rx cp configuration register (address = 5eh) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rxlcd rdpchk pattern rdpchk pattern enable idle cell discard oam check bit de- scramble enable rxcoset enable hec error ignore ro r/w r/w r/w r/w r/w r/w r/w 0 x x x x x x x hec byte verification idle cell filtering user cell filtering insert data path integrity check pattern to rxfifo (within rxutopia interfaceblock) delineated cells from rx e3 framer
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 271 the receive cell processor will compute its version of the hec byte via the generating polynomial x 8 + x 2 + x + 1. the user should be aware that the hec bytes of the incoming cell might have been modulo-2 added with the coset polynomial x 6 + x 4 + x 2 + 1. if this is the case then the receive cell processor must be configured to account for this by writing a ?1? to bit 1 (rx coset enable) of the rx cp configuration register; as depicted below. the ?hec byte error correction/detection? algorithm if the receive cell processor detects one or more errors in the header bytes of a given cell, then the ?hec byte error correction/detection? algorithm will be employed. the ?hec byte error correction/detection? algorithm has two states: detection and correction. figure 73 presents a state machine diagram of the ?hec byte error correc- tion/detection? algorithm. each of these states are discussed below. figure 73. state machine diagram of the hec byte error correction/detection algorithm rx cp configuration register (address = 5eh) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rxlcd rdpchk pattern rdpchk pattern enable idle cell discard oam check bit de- scramble enable rxcoset enable hec error ignore ro r/w r/w r/w r/w r/w r/w r/w 0 x x x x x 1 x correction mode detection mode no error detected multi-bit error detected (cell discarded) no error detected for m consecutive cells single-bit error detected (cell corrected) error detected (cell discarded) alpha consecutive cells with incorrect hec bytes (to hunt state)
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 272 the ?correction? state: when the ?hec byte correction/detection? algorithm is operating in the ?correction mode?, cells with single bit errors (within the header bytes) will be corrected. however, cells with multiple bit errors are discarded, unless con- figured by the user. the user can configure the receive cell processor to retain these cells with multi-bit errors, by writing to bit 0 (hec error ignore) of the rx cp configuration register, as depicted below. writing a ?1? into this bit-field causes the receive cell processor to retain errored cells for further processing. writing a ?0? to this bit-field causes the receive cell processor to discard those cells with multi-bit errors. note: the occurrence of any cells with header byte errors (single-bit or multi-bit errors) will cause the receive cell processor to transition from the ?correction? state to the ?detection? state. monitoring of single-bit errors, during hec byte verification. the user can monitor the number of single bit errors that have been detected by the receive cell processor during hec byte verification. each time the receive cell processor detects a single-bit error, the ?pmon received single- bit hec error count? registers are incremented. these registers are located at addresses 48h and 49h and their bit-formats are presented below. the contents of these registers reflect the total number of single-bit errors that have been detected by the receive cell processor since the last read of this register. these registers are reset upon read. rx cp configuration register (address = 5eh) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rxlcd rdpchk pat rdpchk paten idle cell discard oam chk bit descren rxcoset en hec error ignore ro r/w r/w r/w r/w r/w r/w r/w 0 x x x x x x x address = 48h, pmon received single hec error count - msb bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 s-hec error count?high byte rur rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0 address = 49h, pmon received single hec error count?lsb bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 s-hec error count?low byte rur rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 273 monitoring of multi-bit errors, during hec byte verification the user can also monitor the number of multiple bit errors that have been detected by the receive cell processor, during hec byte verification by reading the pmon received multiple-bit hec error count registers (addresses = 4ah and 4bh). these registers are incremented once for each incoming cell that contains multiple (e.g., more than 1) bit-errors. the bit format of these two registers follow. the contents of these registers reflect the number of cells with multiple-bit errors that have been detected by the receive cell processor, during hec byte verification, since the last read of this register. these registers are reset upon read. the ?detection? state: when the ?hec byte error detection/correction? algorithm is operating in the detection mode, then all errored cells (e.g., those cells with single-bit errors and multi-bit errors) will be discarded, unless configured otherwise by the user. the user can configure the receive cell processor to retain errored cells by writing to bit 0 (hec error ignore) of the rx cp configuration register (address = 5eh), as described above. the ?hec byte error correction/detection? algorithm will transition back into the ?correction? state once the receive cell processor has detected ?m? consecutive cells with the correct hec byte values. the user has the option to use the following values for ?m?: 0, 1, 3, and 7. the user can configure the uni to use any of these values for m by writing the appropriate values to the ?rx cp additional configuration? register (address = 5fh), as depicted below. the definition of the bits relevant to the ?hec byte error correction/detection? algorithm follow: pmon received multiple-bit hec error?msb (address = 4ah) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 m-hec error count?high byte rur rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0 pmon received multiple-bit hec error?lsb (address = 4bh) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 m-hec error count?low byte rur rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0 rx cp additional configuration register (address = 5fh) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused user cell filter discard user cell filter enable correction threshold [1, 0] correct enable unused ro ro r/w r/w r/w r/w r/w ro
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 274 bit 1?correction (mode) enable this ?read/write? bit field allows the user to enable/disable the ?correction mode? portion of the ?hec byte error correction/detection? algorithm. if the user writes a ?0? to this bit-field, this the ?hec byte error correction/detection? algorithm be disabled from entry/operation in the ?correction? mode. therefore, the receive cell processor will only operate in the ?detection? state. if the user writes a ?1? to this bit field then the ?hec byte error correction/ detection? algorithm will transition into and out of the ?correction? mode as dictated by the selected ?correction threshold? value. bits 2 and 3?correction threshold [1, 0] these ?read/write? bit-fields allow the user to select the ?correction? threshold for the ?hec byte error correction/ detection? algorithm. the following table relates the content of these bit-fields to the correction threshold value (m). once again, m is the number of consecutive ?error-free? cells that the receive cell processor must detect before the ?hec byte correction/detection? algorithm will allow a transition back into the ?correction? mode. 7.2.2.3 cell filtering as mentioned earlier, the receive cell processor will filter (e.g., discard) incoming cells based upon the following criteria. ? hec byte errors (via the ?hec byte correction/detection? algorithm, as described in 7.2.2.2.) ? idle cells ? header byte patterns?user cells ? segment oam cells each of these cell filtering approaches are presented below. filtering of cells with hec byte errors please see the ?hec byte correction/detection? algorithm in section 7.2.2.2. table 30. the relationship between corrthreshold[1:0] and the ?correction threshold? value (m) bit 3 bit 2 correction threshold value (m) 0 0 m = 0 0 1 m = 1 1 0 m = 3 1 1 m = 7
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 275 7.2.2.3.1 idle cell filtering the user can configure the receive cell processor to either discard or retain idle cells by writing to bit 4 (idle cell discard) within the ?rx cp configuration? register, as depicted below. if the user writes a ?0? to this bit-field, then the idle cells will be retained and will ultimately be sent on to the user cell filter, within the receive cell processor block. however, if the user writes a ?1? to this bit-field, then the receive cell processor will discard all detected idle-cells. if the user wishes to have the receive cell processor discard the idle cells then he/she must specify the header byte patterns of these idle cells. the idle cell header byte pattern is defined based upon the content of 8 read/write registers. these eight registers are the four ?rx cp idle cell pattern header byte? registers, and the four ?rx cp idle cell mask header?byte? registers. in short, when a cell reaches the ?idle cell filter? portion of the receive cell processor, the contents of each header byte of this cell (bytes 1 through 4), will be compared against the contents of the corresponding ?rx cp idle cell pattern header byte? registers; based upon constraints specified by the contents within the ?rx cp idle cell mask header byte? registers. the user of these registers in ?idle cell identification? and filtering is illustrated in the example below. example?idle cell filtering for example, header byte 1 of a given incoming cell (which may be an idle cell or a user cell) will be subjected to a bit-by-bit comparison to the contents of the ?rx cp idle cell pattern header byte-1? register (address = 62h). the purpose of having the receive cell processor perform this comparison is to determine if this incoming cell is an idle cell or not. the contents of the ?rx cp idle cell mask header byte-1? register (address = 66h) also plays a role in this comparison process. for instances, if bit-field ?0? within the ?rx cp idle cell mask header byte-1? regis- ter contains a ?1?, then the receive cell processor will perform the comparison operation between bit-field ?0? within the ?rx cp idle cell pattern header byte-1? register; and bit-field ?0? within header byte 1 of the newly received cell. conversely, if bit-field ?0? within the ?rx cp idle cell mask header byte-1? register contains a ?0?, then this comparison will not be made and bit-field ?0? will be treated as a ?don?t care?. the role of these two read/ write registers, in these comparison operations is more clearly defined in figure 74, below. rx cp configuration register (address = 5eh) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rxlcd rdpchk pattern rdpchk paten idle cell discard oam chk bit descren rxcoseten hec error ignore ro r/w r/w r/w r/w r/w r/w r/w 0 x x x x x x x content of header byte-1 (of incoming cell) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 1 0 1 0 0 1 0 1 content of ?rx cp idle cell mask header byte-1 register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 1 1 1 1 0 0 0 0
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 276 figure 74. illustration of the role of the ?rx cp idle cell pattern header byte? register, and the ?rx cp idle cell mask header byte? register content of ?rx cp idle cell header byte-1 register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 1 0 1 0 1 1 0 1 comments bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 comparison is forced (by the ?1s? in the rx cp idle cell mask header byte-1 register) don?t care don't care don?t care don?t care header byte-1 identification of idle cell bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 1 0 1 0 x x x x
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 277 based upon these register settings, any cell containing values in the range of a0h?afh are considered be matching the ?idle cell pattern?, at the first byte. this incoming cell will be subjected to three (3) more tests (e.g., one for each of the remaining header bytes.); before it is identified as an idle cell or not. consequently, if the user opts to ?discard? idle cells, then any cells, passing the above-described tests, will be identified as an idle cell and will be discarded by the receive cell processor. the bit format for each of these eight ?idle cell? identification registers are listed below. rx cp idle cell pattern header byte-1 register (address = 62h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx idle cell pattern?header byte 1 r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0 rx cp idle cell pattern header byte-2 register (address = 63h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx idle cell pattern?header byte 2 r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0 rx cp idle cell pattern header byte-3 register (address = 64h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx idle cell pattern?header byte 3 r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0 rx cp idle cell pattern header byte-4 register (address = 65h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx idle cell pattern?header byte r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 278 rx cp idle cell mask header-byte 1 register (address = 66h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx idle cell mask header?byte 1 r/w r/w r/w r/w r/w r/w r/w r/w 1 1 1 1 1 1 1 1 rx cp idle cell mask header?byte 2 register (address = 67h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx idle cell mask header?byte 2 r/w r/w r/w r/w r/w r/w r/w r/w 1 1 1 1 1 1 1 1 rx cp idle cell mask header?byte 3 register (address = 68h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx idle cell mask header?byte 3 r/w r/w r/w r/w r/w r/w r/w r/w 1 1 1 1 1 1 1 1 rx cp idle cell mask header?byte 4 register (address = 69h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx idle cell mask header?byte 1 r/w r/w r/w r/w r/w r/w r/w r/w 1 1 1 1 1 1 1 1
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 279 the user can periodically monitor the number of idle cells that have been detected by the receive cell processor, by reading the ?pmon received idle cell count? register (addresses = 4ch, 4dh). the bit-format of these registers are presented below. the content of these registers are the number of idle cells that have been detected, by the receive cell processor, since the last read of these registers. these registers are reset upon read. 7.2.2.3.2 user cell filtering the user can configure the receive cell processor to filter incoming user or oam cells based upon the value of their header bytes. in all, the uni provides the user with three (3) options. ? disable the user cell filter. ? pass only those cells with header byte patterns matching the settings of the user cell filter. ? discard only those cells with header byte patterns matching the settings of the user cell filter. each of these user-cell filtering options are discussed below. disable the user-cell filter if the user disables the user-cell filter, within the receive cell processor, then all user cells (independent of their header byte patterns) will be written into the rx fifo, within the receive utopia interface block. ?pmon received idle cell count?msb? register (address = 4ch) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx idle cell count?high byte rur rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0 ?pmon received idle cell count?lsb? register (address = 4dh) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx idle cell count?low byte rur rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0 rx cp additional configuration register (address = 5fh) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused user cell filter discard user cell filter enable correct threshold [1, 0] correction enable unused ro ro r/w r/w r/w r/w r/w ro
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 280 writing a ?1? to bit 4 (user cell filter enable) enables the user cell filter. whereas, writing a ?0? to this bit-field dis- ables the user cell filter. enable the user cell filter if the user cell filter is enabled, then the receive cell processor will be filtering user cells in one of two possible manners. 1. pass only those cells with header bytes patterns matching the user cell filter settings (e.g., the contents of the ?rx cp user cell filter pattern header byte? registers), or 2. discard only those cells with header byte patterns matching the user cell filter settings. the user (or assigned) cell filtering criteria is defined based upon the contents of 8 read/write registers. these eight registers are the four ?rx cp user cell filter pattern header byte? registers and the four ?rx cp user cell filter mask header byte? registers. in short, when a user cell reaches the receive cell processor, the contents of each header byte of this cell (bytes 1 through 4), will be compared against the contents of the corresponding ?rx cp user cell filter pattern header byte? registers based upon constraints specified by the contents of the ?rx cp user cell filter mask header byte? registers. the role of these registers in ?user cell filtering? is illustrated in the example below. example?user cell filtering header byte 1 of a given incoming user cell will be subjected to a bit-by-bit comparison to the contents of the ?rx cp user cell filter pattern header byte-1? register (address = 6ah). however, the contents of the ?rx cp user cell filter mask header byte-1? register (address = 6eh) also plays a role in this comparison process. for example, if bit-field ?0? within the ?rx cp user cell filter mask header byte-1? register contains a ?1?, then the receive cell processor will perform the comparison operation between bit-field ?0? within the ?rx cp user cell filter pattern header byte-1? register; and bit-field ?0? within header byte 1 of the newly received user cell. conversely, if bit-field ?0? within the ?rx cp user cell filter mask header byte-1? register contains a ?0?, then this comparison will not be made and bit-field ?0? will be treated as a ?don?t care?. the role of these two read/write registers in these comparison operations is more clearly illustrated in figure 75, below. content of header byte-1 (of incoming user cell) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 1 0 1 0 0 1 0 1 content of ?rx cp user cell filter mask header byte-1 register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 1 1 1 1 0 0 0 0 content of ?rx cp user cell filter pattern header byte-1 register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 1 0 1 0 1 1 0 1
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 281 figure 75. illustration of the role of the ?rx cp user cell filter pattern header byte? register and the ?rx cp user cell filter mask header byte? register. based upon these register settings, any cell containing values in the range of a0h?afh are considered to be matching, at the first byte. this cell will be subjected to three (3) more tests (e.g., one for each of the remaining header bytes.) comments bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 comparison is forced (by the ?1s? in the rx cp user cell fil- ter mask header byte-1 register) don?t care don't care don?t care don?t care resulting ?user cell filter? pattern for header byte-1 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 1 0 1 0 x x x x
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 282 after all of these comparison tests have been performed, a given user cell will be deemed either ?matching? or ?not matching? the settings of the user cell filter. once the cell has been classified into one of these two categories, its disposition (or fate) is dependent upon the content of bit-field 5 (user cell filter discard) within the ?rx cp addi- tional configuration register (address = 5fh). if this bit-field is ?0?, then only-matching cells will be retained, and are written into the rxfifo. all remaining user cells will be discarded. conversely, it this bit-field is ?1?, then only ?non- matching? user cells will be retained and written to the rxfifo. all ?matching? user cells will be discarded. the bit-formats of the 8 registers that define the user cell filtering criteria are presented below. user cell filter header byte pattern registers rx cp user cell filter pattern header?byte 1 (address = 6ah) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx user cell header pattern?byte 1 r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0 rx cp user cell filter pattern header?byte 2 (address = 6bh) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx user cell header pattern?byte 2 r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0 rx cp user cell filter pattern header?byte 3 (address = 6ch) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx user cell header pattern?byte 3 r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 283 user cell filter mask registers rx cp user cell filter pattern header?byte 4 (address = 6dh) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx user cell header pattern?byte 4 r/w r/w r/w r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0 rx cp user cell filter mask header?byte 1 (address = 6eh) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx user cell mask header?byte 1 r/w r/w r/w r/w r/w r/w r/w r/w 1 1 1 1 1 1 1 1 rx cp user cell filter mask header?byte 2 (address = 6fh) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx user cell mask header?byte 2 r/w r/w r/w r/w r/w r/w r/w r/w 1 1 1 1 1 1 1 1 rx cp user cell filter mask header?byte 3 (address = 70h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx user cell mask header?byte 3 r/w r/w r/w r/w r/w r/w r/w r/w 1 1 1 1 1 1 1 1
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 284 7.2.2.4 oam cell processing oam (operation administration and maintenance) cells, are special cells that are generated by the ?layer management? entity (within the bisdn reference model), and are typically used to carry maintenance-related information such as: ? virtual path connection (vpc)/virtual circuit connection (vcc) failure reporting ? vpc/vcc continuity check information ? vpc/vcc continuity verification: oam cell loopback testing ? vpc/vcc performance monitoring oam cells are identified and distinguished from user cells by their specific cell header byte patterns. atm layer entities can typically use one of four types of oam cells. these types of oam cells are listed below. ? f4?segment ? f4?end to end ? f5?segment ? f5?end to end f4 type oam cells usually carry maintenance related information regarding a specific virtual path connection (vpc). whereas f5 type oam cells usually carry maintenance related regarding a specific virtual circuit connec- tion (vcc). the header byte patterns of each of these types of oam cells is tabulated below. where: a?bit is available for use by the atm layer entity z?any vci value other than 0 rx cp user cell filter mask header?byte 4 (address = 71h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx user cell mask header?byte 4 r/w r/w r/w r/w r/w r/w r/w r/w 1 1 1 1 1 1 1 1 table 31. the header byte pattern formats for the various types of oam cells oam cell octet 1 octet 2 octet 3 octet 4 f4 end-to-end 0000aaaa aaaa0000 00000000 01000a0a f4 segment 0000aaaa aaaa0000 00000000 00110a0a f5 end-to-end 0000aaaa aaaazzzz zzzzzzzz zzzz101a f5 segment 0000aaaa aaaazzzz zzzzzzzz zzzz100a
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 285 as far as the XR-T7234 e3 uni ic is concerned, whether an oam cell is an f4 or f5 type oam cell, is rather unim- portant. the receive cell processor circuitry has been designed to recognize both types of oam cells, based upon their header byte pattern. however, whether an oam cell is a ?segment type? or an ?end-to-end type? is more important in regards to uni ic operation. the manner in which the receive cell processor handles ?segment? and ?end-to-end? oam cells is described below. 7.2.2.4.1 segment type oam cells ?segment? type oam cells are only intended for ?point-to-point? transmission. in other words, a segment type oam cell will be created at a source node, transmitted across a single link, to a destination node; and then terminated at this destination node. this segment oam cell is not intended to be read or processed by any other nodes, within the atm network how the receive cell processor handles segment type oam cells the receive cell processor has been designed to recognize incoming oam cells, based upon their header byte pattern. further, the receive cell processor is also capable of reading the header byte patterns, in order to deter- mine if the oam cell is a ?segment? type or an ?end-to-end? type oam cell. if the incoming oam cell is a ?segment? type oam cell, then the receive cell processor will not write this cell to the rx fifo, within the receive utopia interface block and will discard this cell. this act of discarding the oam cell terminates it and prevents it from prop- agating to other nodes in the network. note: if the user configures the user cell filter to pass cells with header bytes pattern ranges that includes that of the ?segment?-type oam cell, then the user cell filter settings will take precedence and will allow the ?segment?- type oam cell to be written to the rx fifo, within the receive utopia interface block. although the receive cell processor will discard this ?segment? oam cell, the user can configure the receive cell processor to have the contents of this cell written into the receive oam cell buffer, where it can be read out and processed by the local m p/ m c. if the user writes a ?1? to bit 3 (oam check bit) within the ?rx cp configuration? register (address = 5eh), then all oam cells that are received by the receive cell processor will be written into the receive oam cell buffer (located at 161h through 1a1h, in the uni chip address space). once the receive cell processor has written the oam cell into the ?receive oam cell? buffer, then the receive cell processor will alert the local m p/ m c of this fact, by generating the ?received oam cell? interrupt. if the user write a ?0? to bit 3 of the ?rx cp configuration? register, then the receive cell processor will not write the contents of the oam cells that it receives, to the ?receive oam cell? buffer. rx cp configuration register (address = 5eh) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rxlcd rdpchk pattern rdpchk pattern enable idle cell discard oam check bit de- scramble enable rxcoset enable hec error ignore ro r/w r/w r/w r/w r/w r/w r/w 0 x x x x x x x
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 286 figure 76 presents an illustration, depicted how the receive cell processor handles incoming segment-type oam cells, if the user has written a ?1? to bit 3 (oam check bit) of the ?rx cp configuration? register. figure 76. an approach to processing segment oam cells, via the receive cell processor. 7.2.2.4.2 end-to-end type oam cells ?end-to-end? type oam cells, as the name implies, are intended for something more than a point-to-point transmis- sion. in other words, an ?end-to-end? type oam cell will be created at a source node, transmitted across a single link, to a destination node. however, in this case, the ?end-to-end? oam cell is not terminated at this destination node; but is rather transmitted across other links to other nodes within the network. how the receive cell processor handles end-to-end type oam cells if the receive cell processor determines that the incoming oam cell is an ?end-to-end? type then it will be written into the rx fifo, within the receive utopia interface block. this act will allow the atm layer processor to read in this oam cell, from the uni and propagate this cell to other nodes in the network. note: the receive cell processor will write the ?end-to-end? oam cell to the rx fifo, independent of the user cell filter settings. the user can also configure the receive cell processor to write the contents of the ?end-to-end? oam cell into the receive oam cell buffer. for details on how this can be done, please see section 7.2.2.4.1. figure 77 presents an illustration, which depicts how the receive cell processor handles incoming end-to-end type oam cells, if the user has written a ?1? to bit 3 (oam check bit) of the ?rx cp configuration? register. figure 77. approach to processing ?end-to-end? oam cells user cell filter receive cell processor rx fifo receive utopia interface block cell delineation hec verification utopia interface path of oam cell oam cell buffer located at address (161h - 1a1h) in on-chip ram. ?segment-type? oam cell is not ?passed through? to the rx fifo inthe receive utopia block user cell filter receive cell processor rx fifo receive utopia interface block cell delineation hec verification utopia interface receive oam cell buffer located at address (161h - 1a1h) in on- chip ram. ?end-to-end? type oam cell is ?passed through? to the rx fifo inthe receive utopia interface block the contents of the oam cell are also written into the ?receive oam cell? buffer
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 287 monitoring the number of user/oam cells the user can monitor the number of valid cells (user and oam) that have been received by the receive cell pro- cessor, by reading the pmon received valid cell count registers (address = 4eh, and 4fh). the bit-format of these registers are presented below. the contents of this register reflects the total number of valid cells that the receive cell processor has received since the last reading of this register. this register is reset upon read. finally, the user can also monitor the total number of cells that have been discarded (either due to hec byte errors, idle cell removal, or user cell filtering) by reading the pmon discarded cell count registers (address = 50h, 51h). the bit-format of this register is presented below. pmon received valid cell count?msb (address = 4eh) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx valid cell count?high byte rur rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0 pmon received valid cell count?lsb (address = 4fh) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rx valid cell count?low byte rur rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0 pmon discarded cell count?msb (address = 50h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 cell drop count?high byte rur rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0 pmon discarded cell count?lsb (address = 51h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 cell drop count?low byte rur rur rur rur rur rur rur rur 0 0 0 0 0 0 0 0
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 288 the contents of these registers reflect the number of cells that have been discarded since the last read of these registers. these registers are reset upon read. 7.3.2.5 cell payload de-scrambling in numerous applications the payload portion of the incoming cells will scrambled by the transmit cell processor, atthe ?far end? transmitting terminal. these cells are scrambled in order to prevent the user data from mimicking framing or control bytes. therefore, the receive cell processor provides the user will the option of de-scrambling the payload of these cells in order to restore the original content of the cell payload. (please note that this cell de-scrambler presumes that the cell payload were scrambled via the scrambling generating polynomial of x 43 + 1.) the user can configure this option by writing a ?1? to bit 2 (de-scramble enable) within the rx cp configuration register, as depicted below. 7.2.2.6 data path integrity check the ?data path integrity? check is a test that is continually ran in order to verify that the connections, throughout the ?atm layer? entity (e.g., from the receive utopia interface of the ?source? uni to the transmit utopia interface of the ?destination? uni) is functioning properly. the manner in which the ?data path integrity check? is employed is as follows. after an incoming cell has passed through the cell delineation, hec byte verification, idle cell filtering and user cell filtering processes, it will be written to the rx fifo, within the receive utopia interface block. however, prior to being written into the rx fifo, the ?data path integrity test? pattern will be written into the 5th octet (overwriting the hec byte) of the ?outbound? cell. this ?data path integrity test? pattern is typically of the value ?55h?, for each outbound cell. however, it can also be configured to be an alternating pattern of ?55h? and aah? (alternating values with each cell). the transmit cell processor, within the ?destination? uni will perform a check of the 5th byte of all cells that it reads from the tx fifo; prior to computing and overwriting this byte with the hec byte. for more information on how the transmit cell processor handles the ?data path integrity check? test patterns, please see section 6.2.2.6. rx cp configuration register (address = 5eh) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rxlcd rdpchk pattern rdpchk pattern enable idle cell discard oam check bit de- scramble enable rxcoset enable hec error ignore ro r/w r/w r/w r/w r/w r/w r/w 0 x x x x x x x
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 289 the receive cell processor?s handling of the data path integrity test pattern the user has a variety of options, when it comes to configuring the receive cell processor to support the data path integrity test. first of all, the user can decide whether or not he/she wishes to even transmit a data path integrity test pattern, via the outbound cell; or just allow the outbound cell, with the hec byte to be written to the rx fifo. the user can configure the receive cell processor per his/her choice, by writing the appropriate value into bit 5 (rdpchk pattern enable) within the ?rx cp configuration register (address = 5eh) as depicted below. writing a ?1? to this bit-field configures the receive cell processor to write the ?data path integrity test? pattern into the 5th octet of each ?outbound? cell, prior to transmittal to the rxfifo. conversely, writing a ?0? to this bit-field con- figures the receive cell processor to write the cell, with the hec byte, into the rxfifo. next, the receive cell processor also allows the user to choose between two possible data path integrity test pat- terns. the user can configure his/her selection by writing the appropriate value to bit 6 (rdpchk pattern) within the ?rx cp configuration? register (address = 5eh). writing a ?1? to this bit-field configures the receive cell proces- sor to write a ?55h? into the 5th octet of each ?outbound? cell, prior to it being written into the rx fifo. conversely, writing a ?0? to this bit-field configures the receive cell processor to write an alternating pattern of ?55h? or ?aah?, into the 5th octet of each ?outbound? cell, prior to it being written into the rxfifo. the receive cell processor will alternate between each of these two patterns with each ?outbound? cell. note: the contents of bit 6, within the rx cp configuration register, is ignored if bit 5 is set to ?0?. 7.2.2.7 gfc nibble extraction?via the rxgfc serial output port the first four bit-field of each cell header are the gfc bits. the receive cell processor will output the contents of the gfc nibble-field for each valid (e.g., user or oam) cell that it receives, via the ?gfc nibble field? serial output port. the ?receive gfc nibble-field? serial output port consists of the following pins. ? rxgfc ? rxgfcclk ? rxgfcmsb rx cp configuration register (address = 5eh) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 rxlcd rdpchk pattern rdpchk pattern enable idle cell discard oam check bit descramble enable rxcoset enable hec error ignore ro r/w r/w r/w r/w r/w r/w r/w 0 x x x x x x x
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 290 the data is output via the rxgfc output pin. the order of transmission, within a given cell, is with the msb first and in descending order until transmitting the lsb bit. afterwards, the ?gfc nibble-field? serial output port will output the msb for the gfc nibble-field of the next valid cell. this data is clocked out on the rising edge of the rxgfcclk output signal. the rxgfcmsb output pin will be pulsed ?high? each time the msb of the gfc nibble field, for a given cell, is present at the rxgfc input. figure 78 presents an illustration depicting the behavior of the rxgfc serial output port signals. figure 78. illustration of the behavior of the rxgfc serial output port signals 7.3.2.8 receive cell processor interrupts the receive cell processor will generate interrupts upon ? hec byte errors ? oam cell received ? loss of cell delineation if one of these conditions occur, and if that particular condition is enabled for interrupt generation, then when the local mc/mp reads the uni interrupt status register, as shown below, it should read ?0xxxx1xxb? (where the -b suffix denotes a binary expression, and ?x? denotes a ?don?t care? value). uni interrupt status register (address = 05h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused one sec interrupt status tx e3 interrupt status rx e3 interrupt status tx cp interrupt status rx cp interrupt status tx utopia interrupt status rx utopia interrupt status ro rur ro ro ro ro ro ro x x x x x 1 x x rxgfcclk rxgfcmsb t52 rxgfc bit 3 bit 2 bit 1 bit 0 t50 t48 t51 t47 t49
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 291 at this point, the local m c/ m p will have determined that the receive cell processor block is the source of the interrupt, and that the interrupt service routine should branch accordingly. in order to accomplish this the local m c/ m p should now read the ?rx cp interrupt status register? (address = 61h). the bit format of this register is presented below. the bit format of the rx cp interrupt status register indicates that only three (3) bit-fields within this register, are active. the role of each of these bit fields follows. bit 0?hec byte error interrupt status a ?1? in this ?reset-upon-read? bit-field indicates that the receive cell processor has detected a hec byte error in an incoming cell, and has requested a ?hec byte error? interrupt, since the last read of this register. bit 1? ?change in lcd (loss of cell delineation) state? interrupt status a ?1? in this ?reset-upon-read? bit-field indicates that the receive cell processor has changed its ?lcd? (loss of cell delineation) state and has issued the ?change in lcd state? interrupt, since the last read of this register. note: this type of interrupt could occur due to a transition from the sync state to the hunt state, in the ?hec byte cell delineation algorithm; during which the rxlcd pin will toggle ?high?. additionally, this type of interrupt could also occur due to the transition from the pre-sync state into the sync state. the user can distinguish between these two possibilities by reading the lcd bit-field (bit 7) within the ?rx cp configuration? register (address = 5eh). bit 2?received oam cell interrupt status a ?1? in this ?reset-upon-read? bit-field indicates that the receive cell processor has detected an oam cell in the path of ?incoming cells?; and has stored the contents of this oam cell in the ?receive oam cell buffer?, since the last read of this register. the purpose of this interrupt is to alert the local m p/ m c that the ?receive oam cell buffer? (within the uni) contains an oam cell that needs to be read and processed. 7.3 receive utopia interface block 7.3.1 brief description of the receive utopia interface block the receive utopia interface block provides a ?utopia level 2? compliant interface to interconnect the uni chip to atm layer or atm adaptation layer processors, operating up to 800 mbps. this interface supports both an 8 and 16 bit wide data bus. since data is received at clock rates independent of the atm layer clock rate, the received cell data is written into an internal fifo by the receive cell processor block. this fifo will be referred to as the rx fifo throughout this document. the receive cell processor will delineate, check for hec byte errors, filter and de-scramble atm cells. whatever cells were not discarded, by the receive cell processor, will be written into the rx fifo, where it can be read out from the uni device, by the atm layer processor. the receive utopia interface block will inform the atm layer processor that it has cell data available for reading, by asserting the rxclav pin ?high?. figure 79 presents a simple illustration of the receive utopia interface block and the associated pins. rx cp interrupt status register (address = 61h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused received oam cell interrupt status lcd interrupt status hec error interrupt status ro ro ro ro ro rur rur rur
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 292 figure 79. simple block diagram of receive utopia block of uni. 7.3.2 functional description of receive utopia the purposes of the receive utopia interface block are to: ? receive filtered atm cell data from the receive cell processor and make this data available to the aal or atm layer processor. ? inform the atm layer processor whenever the rxfifo contains cell data that needs to be read. ? inform the atm layer processor that it has no more cell data to be read. ? compute and present the odd-parity value of the byte (or word) that is present at the receive utopia data bus. ? indicate the boundaries of cells, to the atm layer processor, by pulsing the rxsoc (receive start of cell) pin each time the first byte (or word) of a new cell is present on the receive utopia data bus. ? the receive utopia interface block consists of the following sub-blocks: ? receive utopia output interface ? receive utopia cell fifo (rx fifo) ? receive utopia fifo manager the receive utopia interface block consists of an output interface complying to the ?utopia level 2 interface spec- ifications?, and the rxfifo. the width of the receive utopia data bus is user-configurable to be either 8 or 16 bits. the receive utopia interface block also allows the atm layer processor to perform parity checking on all data that it receives from it (the receive utopia interface block), over the receive utopia data bus. the receive utopia interface block computes the odd-parity of each byte (or word) that it will place on the receive utopia data bus. the receive utopia interface block will then output the value of this computed parity at the rxprty pin, while the corresponding data byte (word) is present at the rxdata[15:0] output pins. receive utopia interface rxclk rxenb* rxprty rxdata[15:0] rxsoc rxclav/rxemptyb* rxaddr[4:0] from receive cell processor
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 293 the receive utopia interface block can be configured to process 52, 53, and 54 bytes per cell; and will assert the rxsoc (receive ?start of cell?) output pin at the cell boundaries. if the receive utopia interface block detects a ?runt? cell (e.g., a cell that is smaller than what the receive utopia interface block has been config- ured to handle), it will generate an interrupt to the local mp, discard this ?runt? cell, and resume normal opera- tion. the physical size of the rx fifo is four cells. the incoming data (from the receive cell processor) is written into the rx fifo, where it can be read in and processed by the atm layer processor. a fifo manager main- tains the rx fifo and indicates the fifo empty and fifo full to the local m p. additionally the fifo manager will indicate that atm cell data is available in the rxfifo, by asserting the rxclav output pin. figure 74 pre- sents a functional block diagram of the receive utopia interface block. figure 80. functional block diagram of the receive utopia interface block the following sections discusses each functional sub-block of the receive utopia interface block in detail. addi- tionally, these sections discuss many the of the features associated with the receive utopia interface block as well as how the user can optimize these features in order to suit his/her application needs. detailed discussion of single-phy and multi-phy operation will be presented in its own section even though it involves the use of all of these functional blocks. 7.3.2.1 receive utopia bus output interface the receive utopia output interface complies with the utopia level 2 standard interface (e.g., the receive uto- pia can support both single-phy and multi-phy operations). additionally, the uni provides the user will the option of varying the following features associated with the receive utopia bus interface. rxutopia registers d[15:0] a[8:0] status signals control signals rx utopia fifo manager rx utopia cell fifo rxdata[15:0] rxdata[7:0] rxaddr[4:0] rxenb rxsoc rxclk rxutopia interrupt rxclav/rxemptyb controls from registers rxfwrclk rwrenb (to pin) (to interrupt block) read write rxfdata[7:0] rxdata[7:0]/ rxdata[15:0] rxsoc status bits to registers rxprty to pins from rx cp
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 294 ? receive utopia data bus width of 8 or 16 bits. ? the cell size (e.g., the number of octets being processed per cell via the utopia bus) a discussion of the operation of the receive utopia bus interface along with each of these options will be presented below. 7.3.2.1.1 the pins of the receive utopia bus interface the atm layer processor will interface to the receive utopia interface block via the following pins. ? rxdata[15:0]?receive utopia data bus output pins ? rxaddr[4:0]?receive utopia address bus input pins ? rxclk?receive utopia interface block clock input pin ? rxsoc?receive ?start of cell? indicator? output pin ? rxprty?receive utopia?odd parity output pin ? rxenb*?receive utopia data bus?output enable input pin ? rxclav/rxfullb*?rxfifo cell available output pin each of these signals are discussed below. rxdata[15:0]?receive utopia data bus output pin the atm layer processor will read atm cell data from the receive utopia interface block in a byte-wide (or word- wide) manner, via these output pins. the receive utopia data bus can be configured to operate in the ?8 bit wide? or ?16 bit wide mode? (see section 7.3.2.1.2). if the ?8-bit wide? mode is selected, then only the rxdata[7:0] output pins will be active and capable of transmitting data. if the 16-bit wide mode is selected, then all 16 output pins (e.g., rxdata[15:0]) will be active. the receive utopia data bus is tri-stated while the active low rxenb* (receive utopia bus - output enable) input signal is ?high?. therefore, the atm layer processor must assert this signal (e.g., toggle rxenb* low) in order to read the atm cell data from the receive utopia interface block. the data on the receive utopia data bus output pins are updated on the rising edge of the receive utopia interface block clock signal, rxclk . note: the 100 pin version of the XR-T7234 device allocates only 8 pins for the receive utopia data bus: rxdata[7:0]. the receive utopia data bus pins: rxdata[15:8] are not available. rxaddr[4:0]?receive utopia address bus input pins these input pins are used only when the uni is operating in the multi-phy mode. therefore, for more information on the receive utopia address bus, please see section 7.3.2.2.2.2. rxclk?receive utopia interface block clock signal input pin the receive utopia block uses this signal to update the data on the receive utopia data bus. the receive utopia interface block also uses this signal to sample and latch the data on the receive utopia address bus pins (during multi-phy operation), into the receive utopia interface block circuitry. this clock signal can run at frequencies of 25 mhz, 33 mhz, or 50 mhz. rxenb*?receive utopia data bus?output enable input the receive utopia data bus is tri-stated while this input signal is negated. therefore, the user must assert this ?active-low? signal (toggle it ?low?) in order to read the byte (or word), from the receive utopia interface block via the receive utopia data bus.
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 295 rxprty?receive utopia?odd parity bit output pin the receive utopia interface block will compute the odd-parity of each byte (or word) of atm cell data that it will place on the receive utopia data bus. the receive utopia data bus will output the value of the computed parity bit at the rxprty output pin, while the corresponding byte (or word) is present on the receive utopia data bus. this features allows the atm layer processor to perform parity checking on the data that it receives from the receive utopia interface block. rxsoc?receive utopia??start of cell? indicator output pin the receive utopia will pulse this output signal ?high?, for one clock period of rxclk, when the first byte (or word) of a new cell is present on the receive utopia data bus. this signal will be ?low? at all other times. rxclav/rxemptyb*?rx fifo cell available/rxempty* this output signal is used to alert the atm layer processor that the rx fifo contains some atm cell data that is available for reading. please see section 7.3.2.2.1 for more information regarding this signal. 7.3.2.1.2 selecting the utopia data bus width (applies to the 160 pin version only) the utopia data bus width can be selected to be either 8 or 16 bits by writing the appropriate data into the utwidth16 bit (bit 0) within the utopia configuration register, as shown below. if the user chooses a utopia data bus width of 8 bits, then only the receive utopia data output pins: rxdata[7:0] will be active. (the output pins: rxdata[15:8] will not be active). if the user chooses a utopia data bus width of 16 bits, then all of the receive utopia data outputs: rxdata[15:0] will be active. the following table relates the value of bit 0 (utwidth16) within the utopia configuration register, to the corresponding width of the utopia data bus. note: 1. the selection of this bit also effects the width of the transmit utopia data bus. 2. the utopia data bus width will be 8 bits, upon power up or reset. therefore, the user must write a ?1? to this bit in order to set the width of the receive utopia (and the transmit utopia) data bus to 16 bits. utopia configuration register: (address = 7ch) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused hand- shake mode m-phy cellof52 bytes tfifodepth[1, 0] utwidth16 ro ro r/w r/w r/w r/w r/w table 32. the relationship between the contents within bit 0 (utwidth16) within the utopia configuration register, and the opera ting width of the utopia data bus value for utwidth16 width of utopia data bus 0 8 bit wide data bus 1 16 bit wide data bus
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 296 3. this option is only available for the 160 pin packaged version of the XR-T7234 device. the 100 pin device only contains 8 receive utopia data bus pins: rxdata[7:0]. rxdata[15:8] are not available in the 100 pin version. 7.3.2.1.3 selecting the cell size (number of octets per cell) the uni allows the user to select the number of octets per cell that the receive utopia interface block will process. specifically, the user has the following cell size options. ? if the utopia data bus width is set to 8 bits then the user can choose: ? 52 bytes (with no hec byte in the cell), or ? 53 bytes (with either a dummy or actual hec byte in the cell) ? if the utopia data bus width is set to 16 bits, then the user can choose: ? 52 bytes (with no hec byte in the cell), or ? 54 bytes (with either a dummy or actual hec byte, and a stuff byte in the cell) the user makes his/her selection by writing the appropriate data to bit 3 (cellof52bytes) within the utopia configura- tion register, as depicted below. the following table specifies the relationship between the value of this bit and the number of octets/cell that the receive utopia interface block will process. note: this selection applies to both the transmit utopia and receive utopia interface blocks. additionally, the shaded selection reflects the default condition upon power up or reset. an advisory to users the user must insure that the atm layer processor only reads in (from the receive utopia interface block) the ?configured? number of octets per cell, following the latest assertion of the rxsoc output pin. if the atm layer processor continues to try to read-in more octets, it will end up reading in in-valid data. utopia configuration register: (address = 7ch) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused hand- shake mode m-phy cellof52 bytes tfifodepth[1, 0] utwidth16 ro ro r/w r/w r/w r/w r/w table 33. the relationship between the value of bit 3 (cellof52bytes) within the utopia configuration register, and the number o f octets per cell that will be processed by the transmit and receive utopia interface blocks cellof52 bytes number of bytes/cells 0 53 bytes when the utopia data bus width is 8 bits. 54 bytes when the utopia data bus width is 16 bits. 1 52 bytes, regardless of the configured width of the utopia data bus
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 297 7.3.2.1.4 parity checking handling of errored cell data received from the receive utopia interface block the receive utopia interface block will compute the odd parity of each byte (or word) of atm cell data it places on the receive utopia data bus. the receive utopia interface block will also output the value of this parity bit via the rxprty pin. the rxprty pin will contain the odd parity value of the byte or word that is residing on the receive utopia data bus. the user has the option to configure the atm layer processor hardware and or software to use this feature. 7.3.2.2 receive utopia fifo manager the rx fifo manager has the following responsibilities. ? monitoring the fill level of the rxfifo, and alerting the atm layer processor anytime the rxfifo contains cell data that needs to be read. ? detecting and discarding ?runt? cells and insuring that the rxfifo can resume normal operation following the removal of the ?runt? cell. ? insuring that the rxfifo can respond properly to an ?overrun? condition, by generating the ?rxfifo overrun condition? interrupt, discarding the resulting ?runt? or errored cell, and resuming proper operation afterwards. receive utopia fifo manager features and options this section discusses the numerous features that are provided by the receive utopia fifo manager. additionally, this section discusses how the user can optimize these features to suit his/her application needs. the receive utopia fifo manager provides the user with the following options. ? handshaking mode (octet level vs cell level) ? resetting the rx fifo ? monitoring the rx fifo 7.3.2.2.1 selecting the handshaking mode (octet level vs cell level) the receive utopia interface block offers two different data flow control modes for data transmission between theatm layer processor and the uni ic. these two modes are: ?octet-level? handshaking and ?cell-level? handshaking; as specified by the utopia level 2, version 8 specifications, and are discussed below. 7.3.2.2.1.1 octet-level handshaking the uni will be operating in the cell-level handshaking mode following power up or reset. therefore, the user will have to set bit 5 (handshake mode), within the utopia configuration register to ?0? in order to configure the uni into the ?octet-level? handshake mode. the main signal that is responsible for data-flow control between the atm layer processor and the receive utopia interface block is the rxclav output pin. when the uni is operating in the octet-level handshake mode, the receive utopia interface block will assert the rxclav output pin, when the rx fifo contains at least one ?read cycle?s? worth of atm cell data. in other words, ifthe utopia data bus width is configured to be 16 bits wide, then the rxclav signal will be asserted when the rxfifo contains at least two bytes of cell data. likewise, if the utopia data bus width is configured to be 8 bits wide, then the rxclav signal will be asserted when the rxfifo contains at least one byte of atm cell data. the
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 298 receive utopia interface block will negate rxclav when the rx fifo has been depleted of any data. therefore, the rxclav pin exhibits a role that is similar to a ?ready ready? indicator in rs-232 based data transmission systems. the atm layer processor is expected to monitor the state of the rxclav pin very closely (either in a tightly polled or interrupt driven approach). the atm layer processor is also expected to respond very quickly to the assertion of rxclav and read out the cell data in order to avoid an ?overrun condition? in the rx fifo. finally, the atm layer processor is expected to do one of two things, whenever rxclav toggles ?low?. 1. quickly halting its reading of data from the receive utopia data bus. 2. or, ?validate? each byte or word of atm cell data that it reads from the receive utopia data bus; by checking the level of the rxclav signal. in this case, the atm layer processor must have the ability to internally remove any atm cell data bytes or words that have been read in, after rxclav has toggled ?low?. figure 81 presents a timing diagram illustrating the behavior of the rxclav pin during reads from the receive utopia interface block, while operating in the octet-level handshaking mode. figure 81. timing diagram of rxclav/rxemptyb and various other signals during reads from the receive utopia, while operating in the octet-level handshaking mode. notes regarding figure 81 1. the receive utopia data bus is configured to be 16 bits wide. hence, the data which the receive utopia interface block places on the receive utopia data bus is expressed in terms of 16 bit words (e.g., w0?w26). 2. the receive utopia interface block is configured to handle 54 bytes/cell. hence, figure 81 illustrates the atm layer processor reading 27 words (w0 through w26) for each atm cell. in figure 81, rxclav is initially ?low? during clock edge #1. however, shortly after clock edge 1, the rxfifo receives atm cell data from the receive cell processor block. at this point, the rxclav signal toggles ?high? indicating that the rxfifo contains at least one ?read-cycle? worth of cell data. the atm layer processor will detect this ?assertion of rxclav? during clock edge #2. consequently, in order to begin reading this cell data, the atm layer processor will then assert the rxenb* input pin. at clock edge #3, the receive utopia interface block detects rxenb* being rxclk rxclav rxenb* rxdata[15:0] rxsoc w2 w3 w4 x w1 w0 1 2 4 3 5 6 7 8 9 10 11 12
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 299 ?low?. hence, the receive utopia interface block then places word w0 on the receive utopia data bus. the atm layer processor latches and reads in w0, upon clock edge #4. in this figure, shortly after the atm layer processor has read in word w1 (at clock edge #5), the rxfifo is depleted which causes rxclav to toggle ?low?. in this figure, the atm layer processor will keep the rxenb* signal asserted, and will read in an ?invalid? word which is denoted by the ?x? in figure 81. shortly thereafter, the rxfifo receives some additional cell data from the receive cell processor, which in turn causes rxclav to toggle ?high?. the atm layer processor then continues to read in words w2 and w3. afterwards, the atm layer processor is unable to continue reading the atm cell data from the receive utopia interface block; and subsequently negates the rxenb* signal; at clock edge #8. the receive utopia inter- face block detects that rxenb* is ?high? at clock edge #8, and in turn, tri-states the receive utopia data bus at around clock edge # 9. finally, prior to clock edge #11, the atm layer processor is able to resume reading in atm cell data from the receive utopia interface block, and indicates this fact by asserting the rxenb* (e.g., toggling it ?low?). the receive utopia interface block detects this state change at clock edge #11 and subsequently places word w4 on the receive utopia data bus. 7.3.2.2.1.2 cell level handshaking the uni will be operating in the ?cell-level? handshaking mode following power up or reset. in the ?cell-level? handshaking mode, when the rxclav output is at a logic ?1?, it means that the rx fifo contains at least one com- plete atm cell of data that is available for reading by the atm layer processor. when rxclav toggles from ?high? to ?low?, it indicates that rx fifo contains less than one complete atm cell. as in the ?octet-level? handshake mode, the atm layer processor is expected to monitor the rxclav output, and quickly respond and read the rx fifo, whenever the rxclav output signal is asserted. the uni can operate in either the ?octet-level? or ?cell-level? handshake mode, when operating in the single-phy mode. however, only the cell-level handshake mode is available when the uni is operating in the multi-phy mode. for more information on single phy and multi phy operation, please see section 7.3.2.2.2. the user can configure the uni to operate in one of these two handshake modes by writing the appropriate data to bit 5 (handshake mode) of the utopia configuration register, as depicted below. the following table specifies the relationship between this bit and the corresponding handshaking mode. note: 1. the handshake mode selection applies to both the transmit utopia and receive utopia interface blocks. 2. 2. since multi-phy mode operation requires the use of ?cell-level? handshaking; this bit is ignored if the uni is utopia configuration register: (address = 7ch) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused handshake mode m-phy cellof52 bytes tfifodepth[1, 0] utwidth16 ro ro r/w r/w r/w r/w r/w table 34. the relationship between the contents of bit 5 (handshake mode) within the utopia configuration register, and the resulting utopia interface handshake mode value resulting handshake mode 0 the utopia interfaces operate in the cell level handshake mode. 1 the utopia interfaces operate in the octet level handshake mode.
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 300 operating in the multi-phy mode. 3. finally, the uni will be operating in the ?cell-level? handshaking mode upon power up or reset. therefore, the user must write a ?0? to this bit in order to configure ?octet- level handshaking? mode. figure 82 presents a timing diagram that illustrates the behavior of various receive utopia interface block signals when the receive utopia interface block is operating in the ?cell level? handshake mode. figure 82. timing diagram of various receive utopia interface block signals, when the receive utopia interface block is operating in the ?cell level? handshake mode. notes regarding figure 82: 1. the receive utopia data bus is configured to be 16 bits wide. hence, the data, which the receive utopia places on the receive utopia data bus, is expressed in terms of 16 bit words: w0 - w26. 2. the receive utopia interface block is configured to handle 54 bytes/cell. hence, figure 82 illustrates the atm layer processor reading in 27 words (w0 through w26) for each atm cell. in figure 82, the atm layer processor is just finishing up its reading of an atm cell. prior to clock edge #2, the rxfifo does not contain enough atm cell data to make up at least one cell. hence, the receive utopia interface block negates the rxclav signal. the atm layer processor detects that the rxclav signal has toggled ?low?; at clock edge #2. hence, the atm layer processor will finish reading in the current atm cell; from the receive utopia interface block of the uni (e.g., words w25 and w26). afterwards, the atm layer processor will negate the rxenb* signal and will cease to read in anymore atm cell data from the receive utopia interface block; until rxclav toggles ?high? again. the rxfifo accumulates enough cell data to make up a complete atm cell shortly before clock edge #5. at this point the receive utopia interface block reflects this fact by asserting the rxclav signal. the atm layer processor detects that the rxclav signal has toggled ?high? at clock edge #5. consequently, the atm layer processor then asserts the rxenb* signal (e.g., toggles it ?low?) after clock edge #5. the receive utopia interface block detects the fact that the rxenb* input pin has been asserted at clock edge #6. the receive utopia interface block then responds to this signaling by placing the first word of the next cell on the receive utopia data bus. afterwards, the atm layer processor continues to read in the remaining words of this cell. 7.3.2.2.1.3 resetting the rx fifo via software command the uni allows the user to reset the rx fifo, via software command, without the need to implement a master reset of the entire uni device. this can be accomplished by writing the appropriate data to bit 6 (rx fifo reset) of rxclk rxclav rxenb* rxdata[15:0] rxsoc w24 w25 w26 w0 w1 w2 w25 w26 1 2 4 3 5 6 7 8 9 31 32 34
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 301 the receive utopia interrupt enable/status register as depicted below. once the user has reset the rxfifo, then the contents of the rx fifo will be ?flushed? and the receive fifo sta- tus register will reflect the ?rxfifo empty? status. 7.3.2.2.1.4 monitoring the rx fifo status the local m p has the ability to poll and monitor the status of the rx fifo via the receive utopia fifo status reg- ister. the bit format of this register is presented below. the following tables define the values for bits 1 and 0 and the corresponding meaning. rxfifo full rx fifo empty 7.3.2.2.2 utopia modes of operation (single phy and multi-phy operation) the uni chip can support both single-phy and multi-phy operation. each of these operating modes are discussed below. receive utopia?interrupt enable/status register (address?7dh) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused rx fifo reset rx fifo overrun interrupt enable unused rcoca interrupt enable rx fifo overrun interrupt enable unused rx fifo coca int. status r/o r/w r/w ro r/w rur ro rur rx ut fifo status register (address = 7fh) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused rxfifo full rxfifo empty ro ro ro ro ro ro ro ro rxfifo full (bit 1) meaning 0 rx fifo is not full. 1 rx fifo is full, and if the next operation by the atm layer processor is not a read operation, then the rx fifo could be overrun. rxfifo empty (bit 0) meaning 0 rx fifo is not empty 1 rx fifo is empty.
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 302 7.3.2.2.2.1 single phy operation the uni chip will be operating in the multi-phy mode upon power up or reset. therefore, the user must write a ?1? into bit 4 of the utopia configuration register; as depicted below; in order to configure the uni into the ?single-phy? mode. writing a ?1? to this bit-field configures the uni to operate in the single-phy mode. writing a ?0? configures the uni to operate in the multi-phy mode. in single-phy operation, the atm layer processor is pumping data into and receiving data from only one uni device, as depicted in figure 83. atm cell data is read from the rx fifo, via the receive utopia data bus, provided that the receive utopia output enable signal (rxenb) is low. the data on the receive utopia data bus is updated on the rising edge of the receive utopia clock (rxclk). the receive utopia interface block will pulse the receive start of cell signal (rxsoc) when the first byte (or word) of a new cell is present on the receive utopia data bus. odd parity of the output byte or word is calculated and output at rxprty pin. figure 83. simple illustration of single?phy operation this section presents a detailed description of ?single-phy? operation. whenever the atm layer processor is responsible for receiving cell data from the receive utopia interface block; it must do the following. 1. check the level of the rxclav pin if the rxclav pin is ?high? then the rxfifo contains some atm cell data that needs to be read by the atm layer processor. in this case, the atm layer processor should begin to read the cell data from the receive utopia interface block. however, if the rxclav pin is ?low?, then the rxfifo does not contain any cell data, that can be read. in this case, the atm layer processor should wait until rxclav toggles ?high? before attempting to read any more cell data from the ?receive utopia interface block?. utopia configuration register: address = 7ch bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused handshake mode m-phy*/s-phy cellof52 bytes tfifodepth [1, 0] utwidth16 ro r/w r/w r/w r/w r/w x x x 1 x xx x e3 uni atm switch (atm layer device) txdata[15:0] rxdata[15:0] txclav txpos txneg rxpos rxneg txflow control input to/from e3 liu rxclav txsoc txenb* txprty txclk rxclk rxsoc rxenb* rxprty rxflow control input rx start of cell input tx start of cell output txlineclk rxlineclk rx read output enable signal tx write enable output rx utopia data bus parity tx utopia data bus parity rx fifo clock signal tx fifo clock signal rx atm cell data tx atm cell data
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 303 note: the actual meaning associated with rxclav toggling ?high? or ?low? depends upon whether the uni is oper- ating in the ?cell level? or ?octet level? handshake modes. 2. assert the rxenb* pin and read the first byte (or word) of the new cell from the receive utopia data bus. once the atm layer processor has detected that rxclav has toggled ?high?, then it should assert the rxenb* input pin (e.g., toggling it ?low?). once the receive utopia interface block has determined that the rxenb* input pin is ?low?, then it will begin to place some cell data onto the receive utopia data bus. if this first byte (or word) is the beginning of a new atm cell, then the atm layer processor should verify that this byte (or word) is indeed the begin- ning of a new cell, by observing the rxsoc output pin (of the uni ic) pulsing ?high? for one clock period of rxclk. 3. compute the odd-parity of the byte (or word) that is being read from the receive utopia data bus, and compare the value of this parity bit with that of the rxprty output pin. this operation is optional, but should be done concurrently while checking for the assertion of the rxsoc output pin. when reading in the subsequent bytes (or words) of the cell, the atm layer must do the following. ? repeat steps 1 and 2. ? if the uni is operating in the octet-level handshake mode; then the atm layer processor should check the rxclav level prior to asserting the rxenb* (receive utopia interface?output enable) pin. the atm layer pro- cessor should only attempt to read the contents of the receive utopia data bus if the rxclav signal is ?high?. ? if the uni is operating in the cell-level handshake mode; then the atm layer processor should check the rxclav signal level just as it (the atm layer processor) is reading in the very last byte (or word) of a given cell. if the rxclav level is ?high?, then the atm layer processor should proceed to read in the next cell from the receive utopia interface block. however, if the rxclav level is ?low?, then the atm layer processor should halt reading in data, when it reaches the end of the cell (that it is currently reading in). ? the atm layer processor should keep a count on the total number of bytes that have been read in since the last assertion of the rxsoc output pin. this will help the atm layer processor to determine when it has reached the boundary of a given cell. the above-mentioned procedure is also depicted in ?flow chart form? in figure 84, and in timing diagram form in
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 304 figures 85 and 86. figure 84. flow chart depicting the approach that the atm layer processor should take when reading cell data from the receive utopia interface, in the single-phy mode. start check the level of the rxclav pin. is rxclav ?high?? is this the first byte (word) of a new cell? is the current cell complete? is there anymore cells to read ? end assert the receive utopia interface block output enable input pin - rxenb*. read in the first byte (word) from the receive utopia data bus. read in the odd-parity value of this byte/ word from the rxpry output pin. check and verify that the rxsoc pin is asserted. perform the following, concurrently reading in the first byte/word of a cell perform the following, concurrently read in the next byte (word) from the receive utopia data bus. read in the odd-parity value of this byte (word) from the rxpry output pin. assert the ?receive utopia data bus output enable input pin - rxenb*. reading in the remaining bytes/words of a cell no yes yes no no no yes yes
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 305 figure 85. timing diagram of atm layer processor receiving data from the uni over the utopia data bus, (single-phy mode/cell level handshaking). notes regarding figure 85: 1. the receive utopia data bus is configured to be 16 bits wide. hence, the data, which the receive utopia inter- face block places on the receive utopia data bus, is expressed in terms of 16-bit words: (e.g., w0?w26). 2. the receive utopia data bus is configured to handle 54 bytes/cell. hence, figure 85 illustrates the atm layer processor reading 27 words (w0 through w26) for each atm cell. 3. the receive utopia interface block is configured to operate in the cell level handshake mode. figure 86. timing diagram of atm layer processor receiving data from the uni over the utopia data bus, (single-phy mode/octet level handshaking). rxclk rxclav rxenb* rxdata[15:0] rxsoc w24 w25 w26 w0 w1 w2 w25 w26 1 2 3 4 5 6 7 8 9 31 32 34 rxclk rxclav rxenb* rxdata[15:0] rxsoc w2 w3 w4 x w1 w0 1 2 3 4 5 6 7 8 9 10 11 12
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 306 notes regarding figure 86: 1. the receive utopia data bus is configured to be 16 bits wide. hence, the data, which the atm layer processor places on the transmit utopia data bus, is expressed in terms of 16 bit words: (e.g., w0?w26). 2. the receive utopia interface block is configured to handle 54 bytes/cell. hence, figure 86 illustrates the atm layer processor reading 27 words (w0 through w26) for each atm cell. 3. the receive utopia interface block is configured to operate in the octet-level handshaking mode. final comments on single-phy mode the rxclav pin exhibits a role that is similar to the ?ready ready? function in rs-232 based data communication. this pin is asserted when the rxfifo contains atm cell data that can be read by the atm layer processor. the rxclav pin will have a slightly different role when the uni is operating in the multi-phy mode. the uni, while operating in single-phy mode, can be configured for either ?octet-level? or ?cell level? handshake modes. in either case, the atm layer processor is expected to poll the rxclav pin before attempting to read in the next byte, word or cell from the rxfifo. 7.3.2.2.2.2 multi-phy operation the uni ic will be operating in the multi-phy mode upon power up or reset. in multi phy operating mode, the atm layer processor may be pumping data into and reading data from several uni devices in parallel. when the uni is operating in multi-phy mode, the receive utopia interface block will support two kinds of operations with the atm layer processor: ? polling for ?available? uni devices. ? selecting which uni (out of several possible uni devices) to read atm cell data from. each of these operations are discussed in the sections below. however, prior to discussing each of these opera- tions, the reader must understand the following. ?multi-phy? operation involves the use of one (1) atm layer pro- cessor and several uni devices, within a system. the atm layer processor is expected to read/write atm cell data from/to these uni devices. hence, ?multi-phy? operation requires, at a minimum, some means for the atm layer processor to uniquely identify a uni device (within the ?multi-phy? system) that it wishes to ?poll?, write atm cell data to, or read atm cell data from. actually, ?multi-phy? operation provides an addressing scheme that allows the atm layer processor to uniquely identify ?utopia interface blocks? (e.g., transmit and receive) within all of the uni devices, operating in the ?multi-phy? system. in order to uniquely identify a given ?utopia interface block?, within a ?multi-phy? system, each ?utopia interface block? is assigned a 5-bit ?utopia address? value. the user assigns this address value to a particular ?receive utopia interface block? by writing this address value into the ?rx utopia address register? (address = 7eh) within its ?host? uni device. the bit-format of the ?rx utopia address register? is presented below. rx utopia address register (address = 7eh) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused rx_utopia_addr[4:0] ro ro ro r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 307 likewise, the user assigns a ?utopia address? value to a particular ?transmit utopia interface block?, within one of the unis (in the ?multi-phy? system) by writing this address value into the ?tx utopia address register? (address = 82h) within the ?host? uni device. the bit-format of the ?tx utopia address register? is presented below. note: the role of the transmit utopia interface block, in multi-phy? operation is presented in section 6.1.2.3.2. 7.3.2.2.2.2.1 atm layer processor ?polling? of the unis, in the multi-phy mode when the uni is operating in the ?multi-phy? mode, the receive utopia interface block will automatically be configured to support ?polling?. ?polling? allows an atm layer processor (which is interface to several uni devices) to determine which unis contain atm cell data that needs to be read, at any given time. the manner in which the atm layer processor ?polls? its uni devices follows. figure 87. an illustration of multi-phy operation with uni devices #1 and #2 figure 87 depicts a ?multi-phy? system consisting of an atm layer processor and two (2) uni devices, desig- nated as ?uni #1? and ?uni #2?. in this figure, both of the unis are connected to the atm layer processor via a common ?transmit utopia? data bus, ?receive utopia? data bus, a common txclav line, a common rxclav line, as well as common txenb*, rxenb*, txsoc and rxsoc lines. the atm layer processor will also be tx utopia address register (address = 82h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused tx_utopia_addr[4:0] ro ro ro r/w r/w r/w r/w r/w 0 0 0 0 0 0 0 0 txdata[15:0] txaddr[4:0] txprty txenb* txsoc txclav rxdata[15:0] rxaddr[4:0] rxprty rxenb* rxsoc rxclav uni # 1 txaddr = 00h rxaddr = 01h txdata[15:0] txaddr[4:0] txprty txenb* txsoc txclav rxdata[15:0] rxaddr[4:0] rxprty rxenb* rxsoc rxclav txaddr = 02h rxaddr = 03h txdata[15:0] ut_addr[4:0] tx_parity tx_ut_wr* tx_soc_out txclav_in rxdata[15:0] rx_parity rx_ut_rd* rx_soc_in rxclav_in atm layer processor uni # 2
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 308 addressing the transmit and receive utopia interface block via a common ?utopia? address bus (ut_addr[4:0]). therefore, the transmit and receive utopia blocks, of a given uni must have different addresses; as depicted in figure 87. the utopia address values, that have been assigned to each of the transmit and receive utopia interface blocks, within figure 87, are listed below in table 36. recall, that the receive utopia interface blocks were assigned these addresses by writing these values into the ?rx utopia address register? (address = 7fh) within their ?host? uni device. the discussion of the transmit utopia interface blocks, within unis #1 and #2 is presented in section 6.1.2.3.2.1. polling operation consider that the atm layer processor is currently reading a continuous stream of cells from uni #1. while read- ing this cell data from uni #1, the atm layer processor can also ?poll? uni #2 for ?availability? (e.g., tries to deter- mine if the rxfifo, within uni #2, contains some atm cell data that needs to be read). the atm layer processor?s role in the ?polling? operation the atm layer processor accomplishes this ?polling? operation by executing the following steps. 1. assert the rxenb* input pin (if it not asserted already). the uni device (being ?polled?) will know that this is only a ?polling? operation, if the rxenb* input pin is asserted, prior to detecting its utopia address on the ?utopia address? bus. 2. the atm layer processor places the address of the receive utopia interface block of uni #2 onto the utopia address bus, ut_addr[4:0], 3. the atm layer processor will then check the value of its ?rxclav_in? input pin (see figure 87). the uni devices role in the ?polling? operation uni #2 will sample the signal levels placed on its rx utopia address input pins (rxaddr[4:0]) on the rising edge of its ?receive utopia interface block? clock input signal, rxclk. afterwards, uni #2 will compare the value of these ?receive utopia address bus input pin? signals with that of the contents of its ?rx utopia address register? (address = 7fh). if these values do not match (e.g., rxaddr[4:0] ? 03h) then uni #2 will keep its ?rxclav? output signal ?tri-stated?; and will continue to sample its ?receive utopia address bus input? pins, with each rising edge of rxclk. if these two values do match (e.g., rxaddr[4:0] = 03h) then uni #2 will drive its ?rxclav? output pin to the appropri- ate level, reflecting its rxfifo ?fill status?. since the uni is automatically operating in the ?cell level handshaking? mode, while it is operating in the ?multi-phy? mode, the uni will drive the rxclav output signal ?high? if it contains table 35. utopia address values of the utopia interface blocks illustrated in figure 87 block utopia address value transmit utopia interface block?uni #1 00h receive utopia interface block?uni #1 01h transmit utopia interface block?uni #2 02h receive utopia interface block ?uni #2 03h
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 309 at least one complete cell of data that needs to be read by the atm layer processor. conversely, the uni will drive the ?rxclav? output signal ?low? if its rxfifo is depleted, or does not contain at least one full cell of data. when uni #2 has been selected for ?polling?, uni #1 will continue to keeps its ?rxclav? output signal ?tri-stated?. therefore, when uni #2 is driving its ?rxclav? output pin to the appropriate level; it will be driving the entire ?rxclav? line, within the ?multi-phy? system. consequently, uni#1 will also be driving the ?rxclav_in? input pin of the atm layer processor (see figure 87). if uni #2 drives the ?rxclav? line ?low?, upon the application of its address on the utopia address bus, then the atm layer processor will ?learn? that uni #2 does not contain any atm cell data that is ready to be read. however, if uni #2 drives the rxclav line ?high? (during ?polling?), then the atm layer processor will know that uni#2 contain at least one cell of data that needs to be read. figure 88 presents a timing diagram, that depicts the behavior of the atm layer processor?s and the uni?s signals during polling. figure 88. timing diagram illustrating the behavior of various signals from the atm layer processor and the uni, during polling. notes regarding figure 88: 1. the receive utopia data bus is configured to be 16 bits wide. hence, the data, which the atm layer processor places on the receive utopia data bus, is expressed in terms of 16 bit words: (e.g., w0?w26). 2. the receive utopia interface block is configured to handle 54 bytes/cell. hence, figure 88 illustrates the atm layer processor reading 27 words (w0 through w26) for each atm cell. 3. the atm layer processor is currently reading atm cell data from the receive utopia interface block, within uni #1 (rxaddr[4:0] = 01h) during this ?polling process?. 4. the rxfifo, within uni#2?s receive utopia interface block (rxaddr[4:0] = 03h) is either depleted or does not contain enough data to constitute a complete atm cell. hence, the rxclav line will be driven ?low? whenever this particular receive utopia interface block is ?polled?. 5. the receive utopia address of 1fh is not associated with any uni device, within this ?multi-phy? system. hence, the rxclav line is tri-stated whenever this address is ?polled?. note: although figure 87 depicts connections between the transmit utopia interface block pins and the atm layer processor; the transmit utopia interface operation, in the multi-phy mode, will not be discussed in this section. please see section 6.1.2.3.2.1 for a discussion on the transmit utopia interface block during multi-phy operation. 7.3.2.2.2.2.2 reading atm cell data from a different uni after the atm layer processor has ?polled? each of the uni devices, within its system, it must now select a uni, rxclk rxaddr[4:0] rxclav rxenb* rxdata[15:0] rxsoc 01h 1fh 03h 1fh 01h 03h 1fh 03h 01h 1fh 01h 03h w27 w0 w1 w2 w3 w4 w5 w6 w7 w8 w9 w10 01h 03h 01h 03h 03h 01h 01h 1 2 4 3 5 6 7 8 9 10 11 12
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 310 and begin reading atm cell data from that device. the atm layer processor makes its selection and begins the reading process by: 1. applying the utopia address of the ?target? uni on the ?utopia address bus?. 2. negate the rxenb* signal. this step causes the ?addressed? uni to recognize that it has been selected to transmit the next set of atm cell data to the atm layer processor. 3. assert the rxenb* signal. 4. check and insure that the rxsoc output pin (of the selected uni) pulses ?high? when the first byte or word of atm cell data has been placed on the receive utopia data bus. 5. begin reading the atm cell data in a byte-wide (or word-wide) manner from the receive utopia data bus. figure 89 presents a flow-chart that depicts the ?uni device selection and read? process in multi-phy operation. figure 89. flow-chart of the ?uni device selection and read procedure? for the multi-phy operation. figure 90 presents a timing diagram that illustrates the behavior of various ?receive utopia interface block? signals, start poll all unis within the ?multi-phy? system. determine which unis contain atm cell data that needs to be read. select ?availble? uni 1. apply utopia address of the ?selected? receive utopia interface block onto the ?utopia address? bus. 2. negate the rxenb* signal. begin reading atm cell data into ?selected? uni 1. assert rxenb*. 2. read in the first byte/word of atm cell from the receive utopia data bus & check for the asserted rxsoc signal. continue to read in atm cell data. check the rxclav level while reading in the last byte (word) of the current cell. is rxclav ?high? ? wait for rxclav to toggle ?high? is rxclav ?high? ? does the atm layer processor wish to read more cells from the ?selected? uni? yes no yes yes no no
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 311 during the ?multi-phy? uni device selection and read operation. figure 90. timing diagram of the receive utopia data and address bus signals, during the ?multi-phy? uni device selection and write operations. notes regarding figure 90: 1. the receive utopia data bus is configured to be 16 bits wide. hence, the data, which the receive utopia interface block places on the receive utopia data bus, is expressed in terms of 16-bit words (e.g., w0?w26). 2. the receive utopia interface block is configured to handle 54 bytes/cell. hence, figure 90 illustrates the atm layer processor reading 27 words (e.g., w0 through w26) for each atm cell. in figure 90, the atm layer processor is initially reading atm cell data from the receive utopia interface within uni #2 (rxaddr[4:0] = 03h). however, the atm layer processor is also polling the receive utopia interface block within uni #1 (rxaddr[4:0] = 01h) and some ?non-existent? device at rxaddr[4:0] = 1fh. the atm layer processor completes its reading of the cell from uni #1 at clock edge #4. afterwards, the atm layer will cease to read any more cell data from uni #1, and will begin to read some cell data from uni #2 (rxaddr[4:0] = 03h). the atm layer processor will indicates its intention to select a new uni device for reading by negating the rxenb* signal, at clock edge #5 (see the shaded portion of figure 90). at this time, uni #1 will notice two things: 1. the utopia address for the receive utopia interface block, within uni #1 is on the receive utopia address bus (rxaddr[4:0] = 01h). 2. the rxenb* signal has been negated. uni #1 will interpret this signaling as an indication that the atm layer processor is going to be performing read operations from it. afterwards, the atm layer processor will begin to read atm cell data from the receive utopia interface block, within uni #1. 7.3.2.3 receive utopia interrupt servicing the receive utopia interface block will generate interrupts upon the following conditions: ? change of cell alignment (e.g., the detection of ?runt? cells) ? rx fifo overrun if one of these conditions occur and if that particular condition is enabled for interrupt generation, then when the rxclk rxaddr[4:0] rxclav rxenb* rxdata[15:0] rxsoc 01h 1fh 03h 1fh 01h 03h 1fh 01h 03h 1fh 03h 01h w0 w1 w2 w3 w4 w5 w6 w26 w25 w24 w23 cell received from 03h cell received from 01h 01h 03h 01h 03h 01h 03h 03h 1 2 4 3 5 6 7 8 9 10 11 12
xr xr e3 uni for atm xrt7234 preliminary rev. p1.0.0 312 local mp/mc reads the uni interrupt status register, as shown below, it should read ?0xxxxxx1b? (where the -b suffix denotes a binary expression, and the -x denotes a ?don?t care? value). at this point, the local m c/ m p has determined that the receive utopia interface block is the source of the interrupt, and that the interrupt service routine should branch accordingly. the next step in the interrupt service routine should be to determine which of the two receive utopia block inter- rupt conditions has occurred and is causing the interrupt. in order to accomplish this, the local m p/ m c should now read the ?rx ut interrupt enable/status register, which is located at address 7dh in the uni device. the bit format of this register is presented below. the rx ut interrupt enable/status register has eight bit-fields. however, only four of these bit-fields are relevant to interrupt processing. bits 0?2 are the interrupt status bits and bits 3?5 are the interrupt enable bits; for the receive utopia interface block. each of these ?interrupt processing relevant? bit-fields are defined below. uni interrupt status register (address = 05h) bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused one sec interrupt status tx e3 interrupt status rx e3 interrupt status tx cp interrupt status rx cp interrupt status tx utopia interrupt status rx utopia interrupt status ro rur ro ro ro ro ro ro 0 x x x x x x 1 address = 7dh, rx ut interrupt enable/status register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused rxfifo reset rxfifo overflw interrupt enable unused rcoca interrupt enable rxfifo overflw interrupt status unused rcoca interrupt status ro r/w r/w ro r/w ro ro rur
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 313 bit 0?rcoca interrupt status?receive utopia change of cell alignment condition if the rxfifo manager detects a ?runt? cell, then it will generate the ?receive utopia change of cell alignment condition? interrupt, and the ?runt? cell will be discarded. the receive utopia interface block will indicate that it is generating this kind of interrupt by asserting bit 0 (rcoca interrupt status) of the receive utopia interrupt enable/ status register, as depicted below. bit 2?rx fifo overflw interrupt status?rxfifo overrun condition if the rxfifo is filled to capacity, and if the atm layer processor is unable to begin reading its contents, before the receive cell processor writes another cell into the rxfifo, some of the data within the rxfifo will be overwritten, and in turn lost. if the receive utopia interface block detects this condition, and if this interrupt condition has been enabled then the uni will assert the int* pin to the local m p/ m c. additionally, the uni will set bit 2, within the receive utopia interrupt enable/status register to ?1? as depicted below. note: the user (or atm layer processor) must deplete this register before this interrupt condition will be reset. the user can deplete this register by commanding a ?reset? of the rxfifo (e.g., writing ?01xxxxxxb? to this register). bit 3?rcoca interrupt enable?receive utopia change of cell alignment interrupt enable this ?read/write? bit-field allows the user to enable or disables the generation of interrupts due to a detected ?change of cell alignment? condition, within the rxfifo. the local m p/ m c can enable this interrupt by writing a ?1? to this bit-field. upon power up or reset conditions, this bit-field will contain a ?0?. therefore the default condition is for this interrupt to be disabled. bit 5?rxfifo overflw interrupt enable?rx fifo overrun condition interrupt enable this ?read/write? bit-field allows the user to enable or disable the generation of interrupts due to an ?rx fifo overrun? condition. the local m p/ m c can enable this interrupt by writing a ?1? to this bit-field. upon power up or reset conditions, this bit-field will contain a ?0?. therefore, the default condition is for this interrupt to be disabled. address = 7dh, rx ut interrupt enable/status register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused rxfifo reset rxfifo overflw interrupt enable unused rcoca interrupt enable rxfifo overflw interrupt status unused rcoca interrupt status ro r/w r/w ro r/w ro ro rur 0 0 x 0 1 x 0 1 address = 7dh, rx ut interrupt enable/status register bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 unused rxfifo reset rxfifo overflw interrupt enable unused rcoca interrupt enable rxfifo overflw interrupt status unused rcoca interrupt status ro r/w r/w ro r/w ro ro rur 0 0 1 0 x 1 0 x
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 314 8.0 timing diagrams figure 91.XR-T7234 transmit utopia interface block timing txdata[15:0] txen* txprty txsoc txaddr[4:0] txclav txclk t1 t3 t2 t5 t7 t6 t8 t4 t9 t10 t11 t12
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 315 figure 92.gfc nibble-field serial input interface (at transmit cell processor) timing figure 93.transmit e3 framer?oh bit serial input port interface timing txgfcclk txgfcmsb t14 txgfc t16 bit 3 bit 2 bit 1 bit 0 t17 t13 t15 txohframe txoh txohins txohclk t25 t26 t27 t29 t28 t24
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 316 figure 94. transmit e3 framer line interface output timing (txpos and txneg are updated on the rising edge of txlineclk ) figure 95. transmit e3 framer line interface output timing (txpos and txneg are updated on the falling edge of txli- neclk) txlineclk txpos txneg t32 t30 t33 txlineclk txpos txneg t31 t32 t33
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 317 figure 96.receive e3 framer?oh bit serial output port interface timing figure 97.receive e3 framer line interface input signal timing (rxpos and rxneg are sampled on rising edge of rxlineclk) rxohframe rxohclk rxoh t35 t36 t37 t34 fa1[7] fa1[6] fa1[5] fa1[4] fa1[3] rxlineclk rxpos rxneg t38 t39 t42
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 318 figure 98.receive e3 framer line interface input signal timing (rxpos and rxneg are sampled on the falling edge of rxlineclk) figure 99.gfc nibble-field serial output port timing (receive cell processor) rxlineclk rxpos rxneg t40 t41 rxgfcclk rxgfcmsb t52 rxgfc bit 3 bit 2 bit 1 bit 0 t50 t48 t51 t47 t49
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 319 figure 100.receive utopia interface block timing rxdata[15:0] rxen* rxprty rxsoc rxaddr[4:0] rxclav rxclk t54 t57 t60 t61 t62 t63 t53 data valid t55 t58 t59 valid address address of another uni address of another uni t56
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 320 figure 101.microprocessor interface timing?read and write operations a8 - a0 cs* wrb_rw (wr*) d15 - d0 (read) float not valid valid float d15 - d0 (write) valid t64 t66 t65 t67 t74 t72 t73 t70 t74 t71 rdb_ds (rd*) t69 ale_as (ale) t68 t69
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 321 figure 102.intel type processors, non-burst mode wrb_rw (r/w*) cs* ale_as (as*) rdb_ds (ds*) d15 - d0 valid data a8 - a0 address being read t75 t76 t77 t78 t83 t84 t80 t82 t79 rdy_dtck (dtack*) t81 t85
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 322 figure 103.microprocessor interface timing?motorola type processors (read operations) non-burst mode wrb_rw (r/w*) cs* ale_as (as*) rdb_ds (ds*) d15 - d0 valid data a8 - a0 address being written to t75 t76 t77 t86 t87 t82 t79 rdy_dtck (dtack*) t81 t85 t88
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 323 figure 104.microprocessor interface timing?motorola type processor (write operations) non-burst mode
xrt7234 e3 uni for atm xr xr preliminary rev. p1.0.0 324 figure 105.pin out of the XR-T7234?100 pin package version txohframe 80 txohclk 79 txoh 78 txohins 77 txaisen 76 vdd 75 txlineclk 74 txneg 73 txpos 72 txframeref 71 gnd 70 txinclk 69 rxred 68 rxpred 67 rxlineclk 66 rxneg 65 rxpos 64 rxohframe 63 rxohclk 62 gnd 61 rxoh 60 nc 59 rlos 58 vdd 57 nc 56 gnd 55 gnd 54 rxenb 53 rxaddr2 52 rxaddr0 51 a5 30 a6 29 a7 28 a8 27 wrb_rw 26 rdb_ds 25 csb 24 gnd 23 intb 22 d0 21 d1 20 d2 19 d3 18 width16 17 d4 16 d5 15 d6 14 d7 13 vdd 12 d8 11 d9 10 d10 9 d11 8 moto/intel 7 d12 6 d13 5 d14 4 d15 3 rdy_dtck 2 gnd 1 XR-T7234b
xr xr e3 uni for atm xrt7234 preliminazry rev. p1.0.0 325 figure 106.pin out of the XR-T7234?160 pin package version tcelltxed 120 txoh 119 nc 118 txohins 117 nc 116 txaisen 115 nc 114 vdd 113 txlineclk 112 txneg 111 nc 110 txpos 109 nc 108 txframeref 107 nc 106 gnd 105 nc 104 txinclk 103 nc 102 rxred 101 nc 100 rxlineclk 99 rxneg 98 rxpos 97 rxframe 96 rxohframe 95 nc 94 rxohclk 93 rxais 92 gnd 91 rxoof 90 rxoh 89 nc 87 rxlos 88 rlos 86 vdd 85 nc 84 gnd 83 gnd 82 rxenb 81 nc 40 a7 39 nc 38 a8 37 nc 36 wrb_rw 35 rxgfc 34 rd_ds 33 csb 32 rxlcd 30 gnd 31 intb 29 lloop 28 d0 27 rloop 26 d1 25 txlev 24 d2 23 encodis 22 d3 21 width16 20 d4 19 d5 18 d6 17 d7 16 vdd 15 d8 14 d9 13 reqb 12 d10 11 txframe 10 d11 9 rlol 8 moto/intel 7 dmo 6 d12 5 d13 4 d14 3 taos 2 d15 1 XR-T7234a

▲Up To Search▲

Price & Availability of XR-T7234

	To Download XR-T7234 Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .